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(57) Abstract: A conversational trading system allows a plurality of instruments, for example financial instruments such as foreign 
£2 exchange products, to be traded from a single user interface. The interface includes a deal stack comprising a deal list, a deal detail 

panel and a button bar. The deal list displays deal related information such as status, party, instrument and an instrument and status 
Q related string in a form common to all instruments. Whenever a new quote request is detected, a new conversation is started. This 

may be with the same party as an existing conversation. The conversation is parsed line by line and the user can edit it before it is sent 
\^ to the counterparty. The parser does not store any record of the deal and, along with the interface, may be downloaded as an Applet. 
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CONVF/RSATIONAL DEALING SY STEM 

CROSS REFERENCE TO RELATED APPLICATIONS 

5 This application claims priority to U.S. Application No. 09/753,940 filed 

January 3, 2001 and U.S. Provisional Application Serial No. 60/308,618 filed 
July 30, 2001. The entirety of these applications are hereby incorporated by 
reference. 

FIELD OF THE INVENTION 

10 This invention relates to dealing systems and in particular to 

conversational dealing or trading system dealing in instruments between parties. 
It is particularly, but not exclusively, related to financial trading and dealing 
systems which trade various financial instruments. The invention is particularly 
concerned with the parsing of conversational messages input into the system by 

15 traders. 

BACKGROUND OF THE INVENTION 

It has become commonplace to trade financial instruments using 
computer systems. These have, to a large extent, replaced open outcry trading 
methods in which traders traded face to face on trading floors. Various 

20 computerised trading systems have evolved for trading different instruments such 
as foreign exchange spot (FX Spot), forward rate agreement (FRAs) and other 
instruments. Some systems are anonymous, in that the counterparties to a trade 
do not know the identity of other counterparties in the market until a deal has 
been done. Successful anonymous trading systems have bee operated for a 

25 number of years by EBS Dealing Resources, Inc. and by Reuters pic. The latter 
company has also run a conversational dealing system known as Reuters 2000/1 
which computerises the conversational exchange between traders in reaching a 
deal allowing deal negotiation between traders. 

Existing dealing systems have tended to support traders trading a single 

30 instrument. In large institutions, where a given trader only trades a single 
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instrument this does not cause any difficulties. However, in smaller institutions, 
a foreign exchange trader, for example, may trade several types of instruments for 
one or more currency pairs. It is inconvenient for such a trader to have to use 
several different trading systems or to have to use a mix of computerised systems 

5 and traditional trading methods such as voice brokers. 

There is, therefore, a need for a system which integrates trading of a 
number of instruments on a single platform to simplify trading, particularly for 
traders in smaller institutions. 

Financial markets such as foreign exchange markets can operate at 

10 extreme speed. Dealers are required to react to market activity nearly 

instantaneously to avoid losing potential deals. As a result, the trader terminal 
must be visually very simple and easy for the trader to assimilate new or changing 
information. The ability to trade a number of different instruments from a single 
terminal adds to the complexity and can lead to more information being 

15 presented to the trader. 

At any one time, a trader may be involved in many deals, some which 
will mature into done deals and others which will be cancelled at some stage 
prior to completion. These deals may be in a variety of instruments. Each of 
these deals will have instrument specific information which the trader must be 

20 able to see to enable him to make the deal. However, displaying all this 

information on the screen makes the screen visually hard to interpret for the 
trader and is, therefore, not desirable. 

Reuters pic operates a conversational dealing system under the 
trademark REUTERS DEALING 2000/1. In this system, traders type 

25 conversation text into the terminals which relates to deals they want to execute. 
The conversation text may have no deal related content or may include 
information related to die deal. The system passes the conversation as it entered 
into the system, on a character by character basis. When a deal is completed the 
parties are asked to confirm the deal and may renegotiate the deal terms. 
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Although the Reuters 2000/1 system has operated successfully for a 
number of years, we have appreciated that the approach taken to parsing has a 
number of disadvantages. The present invention, in its various aspects, aims to 
overcome those disadvantages and to provide improved parsing in a 

5 conversational dealing system and, in turn, to improve the usefulness and 
acceptability of such a system to traders and institutions. 
SUMMARY OF THE INVENTION 

A first aspect of the invention resides in the use of parsing to detect 
terms in conversation which indicate a change in deal status. 

10 More specifically, there is provided a conversational dealing system for 

trading instruments between counterparties, comprising: a plurality of trader 
terminals each having a user interface for inputting and displaying to the trader 
conversational messages including deal related information, the trader terminals 
communicating with each other via a communications network, the trader 

15 terminals each further comprising a parser for parsing said inputted 

conversational messages, said parser comprising: means for analysing the 
conversational messages to detect a change in the status of a deal, the deal having 
a plurality of possible statuses; means for analysing the conversational messages to 
detect deal related information relevant to said detected status of the deal; and 

20 means for returning a parsed message comprising the deal status and relevant 
deal related information to the user interface. 

Embodiments of this aspect of the invention have the advantage that 
parsing of conversations is greatly simplified. In the first instance the parser needs 
to detect changes in status between one of only a few possible deal statuses. 

25 When a change of status has been detected there is only a limited number of 
terms of deal related information that are relevant to that status making parsing 
very simple. 

A second aspect of the invention performs parsing on complete 
conversational messages provided from the terminal. More specifically, there is 
30 provided a conversational dealing system for trading instruments between 
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counterparties, comprising: a plurality of trader terminals each having a user 
interface for inputting and displaying to the trader deal related information as 
conversational messages, the trader terminals communicating with each other via 
a communications network, the trader terminals each further comprising a parser 
5 for parsing said inputted conversational message, wherein said parser includes: 
means for receiving complete conversational messages from the user interface and 
for analysing the complete messages to detect deal related information and form 
a parsed message; and means for returning the parsed message to the user 
interface. 

10 Parsing complete lines of conversation is highly advantageous as it 

enables a structured approach to parsing to be adopted in which the message can 
be parsed to look for a first function, such as change in deal status, and then 
parsed in a manner dictated by the first function. This is not possible in prior art 
systems which parse character by character. 

1 5 A third aspect of the invention enables the user to view and alter parsed 

messages before they are sent to the counterparty. 

More specifically, there is provided a conversational dealing system for 
trading instruments between counterparties, comprising: a plurality of terminals 
each having a user interface for inputting and displaying to the trader deal related 

20 information as conversational messages, the trader terminals communicating with 
each other via a communications network, the trader terminals each further 
comprising a parser for parsing said inputted conversational message, wherein 
said parser includes: means for analysing conversational messages from the user 
interface to detect deal related information and form a parsed message; means for 

25 returning the parsed message to the user interface and displaying the parsed 

message; and means for confirming or altering the parsed message content prior 
to transmission of message to a counterparty trader terminal. 

Once a parsed message has been formed, the user may accept it, edit it 
or cancel it. The counterparty will only see the final message that is sent, if any. 

30 Thus, if a trader makes a mistake, changes his mind, or the market conditions 
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suddenly change, the trader can change or delete a message that would otherwise 
have been sent. Not only is this convenient to the trader, it is highly 
advantageous to the trader's market position as he does not have to reveal his 
trading position and his thought processes until he is happy with his position. In 

5 prior art systems, in which conversations are parsed as they are typed in, this is 
not possible. Although either party can cancel or try to amend the terms of a deal 
once it has been completed, they have, by then, revealed their hand to the 
counterparty, which is undesirable. 

A further aspect of the invention enables more that one conversation to 

10 be current with the same counterparty at any one time. If the parser detects 
information relating to a new deal at any time, regardless of the status of the 
present deal, it notifies the user interface and a new conversation, or deal, is 
initiated. 

More specifically, there is provided a conversational dealing system for 
15 trading instruments between counterparties, comprising: a plurality of trader 
terminals each having a user interface for inputting and displaying to the trader 
deal related information as conversational messages, the trader terminals 
communicating with each other via a communications network, the trader 
terminals each further comprising a parser for parsing said inputted 
20 conversational messages, wherein said parser includes: means for analysing 

conversational messages from the user interface to detect deal related information 
and form a parsed message; and means for returning the parsed message to the 
user interface and displaying the parsed message; wherein the system further 
comprises: means for initiating a deal with a counterparty on request from a 
25 trader; and means for initiating a further deal with the same counterparty on 

detection by the parser of deal related information relating to a deal additional to 
a current deal. 

A system embodying this aspect of the invention has the advantage of 
being highly flexible and reacts to the way in which traders work and think. If a 
30 trader, at any stage of negotiating a deal with a counterparty, asks for a quote on 
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an unrelated deal, the system will detect that quote request and initiate a new 
deal. Both deals, and any further new deals can progress together but completely 
independently of each other. Prior art systems only enable a single conversation 
to be held within a given counterparty at any one time. 

5 In a further aspect of the invention, a parser is dumb in that it retains no 

knowledge of the deal making process. The parser parses a line of conversation 
and returns a file comprising the deal status and related deal information. 

More specifically, there is provided conversational dealing system for 
trading instruments between counterparties, comprising: a plurality of trader 

10 terminals each having a user interface for inputting and displaying to the trader 
deal related information as conversational messages, the trader terminals 
communicating with each other via a communications network, the trader 
terminals each further comprising a parser for parsing said inputted 
conversational messages, wherein said parser includes: means for analyzing 

15 conversational messages from the user interface to detect deal related information 
and form a parsed message; and means for returning the parsed message to the 
user interface and displaying the parsed message; whereifi on returning the 
parsed message to the user interface, the parser retains no record of the parsed 
message or the deal to which it relates. 

20 Embodiments of this aspect of the invention have the advantage that the 

parser is very simple. Furthermore, as the parser stores no historical information 
it is easy to download it to the user, for example as an Applet, each time the user 
logs on to the system. This makes the system suitable for use in an Internet 
environment and makes it very easy for traders to access the system as they not 

25 have to load the parser onto their workstations themselves. It also reduces the 
overheads on IT support in user organisations such as banks or odier financial 
organisations. 

In a further aspect of the invention, a level of filtering of parsed 
messages is introduced between trader terminals. This allows parsed messages to 



37743 v1; T4F011.DOC 



WO 03/012588 



PCT/US02/24021 



be checked to ensure that they conform to the business or operating rules of the 
system. 

More specifically, there is provided a conversational dealing system for 
trading instruments between counterparties, comprising: a plurality of trader 

5 terminals each having a user interface for inputting and displaying to the trader 
deal related information as conversational messages, the trader terminals 
communicating with each other via a communications network, the trader 
terminals each further comprising a parser for parsing said inputted 
conversational messages, wherein said parser includes: means for analyzing 

10 conversational messages from the user interface to detect deal related information 
and form a parsed message; and means for returning the parsed message to the 
user interface and displaying the parsed message; wherein the system further 
comprises: a server for receiving parsed messages including deal related 
information from trader terminals and distributing the parsed messages to 

15 destination terminals, the server including means for check the acceptability of 
parsed messages sent from a trader terminal prior to communication to a 
destination trader terminal and for rejecting unacceptable parsed messages 
without passing the rejected message to the destination trader terminal. 

This aspect of the invention has the advantage that illegal deals can be 

20 filtered out without a deal being agreed on by the parties. Moreover, the filtering 
may include a credit check to ensure that each party has sufficient resources to 
complete the deal. A credit check may be integrated into an institutional credit 
system which typically set limits on the trades that can be completed with any 
counterparty over a set period of time. 

25 If the parsed message is rejected as unallowable, the intended recipient 

has no knowledge that the message was ever sent. This is advantageous as the 
trader does not disclose information as to his dealing position except when trades 
are possible. 
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This aspect of the invention is also advantageous as it prevents traders 
wasting time, often in a very volatile and fast moving market, on trades which 
would otherwise be rejected as unallowable once they had been concluded. 

In a further aspect of the invention, messages displayed at the user 
5 interface are colour coded according to origin. 

More specifically, there is provided a conversational dealing system for 
trading instruments between counterparties, comprising: a plurality of trader 
terminals each having a user interface for inputting and displaying to the trader 
conversational messages including deal related information, the trader terminals 
10 communicating with each other via a communications network, wherein the 
conversational message are displayed in a colour coded form to indicate to the 
user the origin of the conversational messages. 

In one preferred embodiment, messages generated by the user are 
shown in a first colour, messages generated by a counterparty in a second colour, 
15 and messages generated by the system, in a third colour. System messages may 
include parsed messages based on user or counterparty input conversational 
messages. 

Preferably, warning messages, error or danger messages are each shown 
in a further colour. 

20 This aspect of the invention has the advantage of making the user display 

much more intelligible. This is very important in a fast moving market in which a 
trader may have many deals pending at any time and in which he is required to 
analyse deal information very quickly. 
BRIEF DESCRIPTION OF THE DRAWINGS 

25 Embodiments of the invention will now be described, by way of example 

only, and widi reference to the accompanying drawings, in which: 
Figure 1 is a schematic diagram of a trading system; 
Figure 2 is a further schematic diagram showing the main functional 
components of a trader terminal; 
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Figure 3 is a view of the user interface of a trader Terminal, according to a 
first embodiment of the invention; 

Figure 4 is a similar view to figure 3 showing a number of conversation 

panels; 

5 Figure 5 is a view of a deal stack within the user interface and showing the 

deal detail panel; 

Figure 6 is a further view of the deal stack and deal detail panel with a 
different deal highlighted in the deal detail panel from figure 5; 

Figure 7 is a further view of the deal stack showing a deal detail panel for 
10 a completed Forwards deal; 

Figure 8 is a further view of the deal stack showing the deal detail panel 
displaying an error box; 

Figure 9 is a still further view of the deal stack showing the deal detail 
panel displaying potentially modifiable fields highlighted; 
15 Figure 10 shows the deal stack with the deal detail panel showing a 

completed F/X Spot deal including the value of the done deal; 

Figure 1 1 shows the deal stack with the deal detail panel showing a 
forward deal with a Spot Rate Query message; and 

Figure 12 shows how the Spot rate query message of figure 11 appears at 
20 the counterparty's deal detail panel as a warning message. 

Figure 13 is a flow chart showing an overview of the parsing process; 

Figure 14a and 14b are flow charts showing the parsing process in more 

detail; 

Figure 15 is a screen shot of a second embodiment of the user interface 
25 showing a parsed message entered by the maker; 

Figure 16 shows the screen of Figure 15 when die parsed message has 
been sent but not picked up; 

Figure 17 shows the taker's interface when die parsed message is received; 

Figure 18 shows the taker's interface when the system is waiting for the 
30 taker to quote; 
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Figure 19 shows the maker's screen when a quote is received; 
Figure 20 shows the maker's screen when a deal has been finalised; 
Figure 21 shows an example of a warning message and an error message 
together with a second conversation being initiated out of the first conversation; 
5 and 

Figure 22 shows a further example of warning messages. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The system illustrated schematically in figure 1 is a conversational dealing 
system for trading a variety of financial instruments. Instruments which may be 

10 traded include, but are not limited to, foreign exchange (F/X) spot, forwards, 
and outrights. Although the following description will concentrate on F/X spot 
and forwards, it is to be understood that this is purely for the purposes of 
illustrating the invention and that the invention is not limited to any particular 
financial instruments or even to financial instruments. It is equally applicable to 

15 the trading of any other fungible such as commodities, metals, etc. 

The illustrative system is preferably an internet based system in which 
traders communicate with other traders from trader terminals across the internet. 
Trades are agreed upon by an exchange of messages between traders. The 
message content is automatically parsed by the system to identify deal related 

20 content for processing. Once the parsing has detected a deal status change, the 
remainder of the deal processing is handled by the deal stack. Deal status change 
need not be entered by conversation but may be directly input from the traders 
terminal, for example by using on screen function buttons or keyboard driven 
menus. Thus, die system also allows users to deal by a simple exchange of deal 

25 content data which is non-conversational and by a mixture of the two methods. 

The following description gives an overview of the trading system within 
which the user interface is used by traders to execute deals. However, it is to be 
understood that this is only one example of a trading system suitable for use with 
die invention. The invention is not limited to any particular trading system but 

30 is applicable to any system in which a trader is trading multiple instruments. Such 
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a system may be internet based or operate on a conventional public or private 
network. It may use a distributed architecture or operate using a central host or 
may be configured in any other manner. 

Referring now to figure 1, a trading system 10 disclosed is based on a 

5 plurality of server farms 12 connected through a system intranet 14. The server 
farms 12 communicate with trader terminals 16 at bank trading floors through a 
communications network, here the Internet 14, and local bank intranets 18. The 
majority of deal processing takes place at trader terminals 16 with deal messages 
being passed by the server farms 12 to counterparty trader terminals 16. The 

10 server farms also pass done deal information to bank back office systems (not 

shown) to enable deal tickets to be produced and trades to be setded. The deals 
are input into the system 16 either directly by the trader or through parsed 
conversation exchanged between traders, as will be described. Parsing takes 
place at the trader terminals. 

15 Figure 2 shows the user terminals 16, as well as one server farm, 

schematically. A plurality of trader terminals 16, two of whom are shown, 
communicate with each other, and with other terminalsj(not shown) by 
exchanging conversational messages via a system server forming part of the server 
farm. Each client terminal 16 has three logical components: a user interface 20, 

20 a communications module 22 and a parser 24. The client terminals are typically 
a suitable computer such as a PC or workstation having conventional 
components such as input devices including a keyboard and a mouse, and a 
monitor, which presents the user interface to a trader. 

The trader terminals 16 and the server 26 communicate via a 

25 communications network which may be a private network or a public network 
such as the Internet, for example via the World Wide Web, as shown in Figure 1. 
The communications module may, for example, be a modem at the trader 
terminal or client local area network, or some other suitable device. 

The parser 24 performs an analysis of conversations exchanged between 

30 trader terminal and extracts deal related information from those conversational 
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exchanges as will be described in detail. The functional components of the 
system: the parser 24, the user interface 20 and the communications software for 
the communication module 22 are preferably downloaded to the trader terminals 
as an applet each time a trader logs on to the system. This means that the client 

5 terminal does not have to store any software in order to access and run the 

system, all of which may be done by accessing a suitable site on the World Wide 
Web. The system 10 may be used by a trader no matter where he or she is 
located. However, as will be seen, the system is intended to trade very large 
amounts of currency and currency products, as well as other fungibles, and, in 

10 practice, is restricted to banks and other institutions of proven credit worthiness. 
Nevertheless* the portability and flexibility of the system is advantageous to 
traders and is not available in prior art conversational dealing systems in which 
access is limited to a proprietary network. 

In the preferred embodiment, the sever 26 includes a deal server 28 and a 

15 chat server 30. These form a part of the server farm of figure 1 . The deal server 
acts to verify the details of proposed deals against business and banking rules and 
allows other checks to be made before a proposed deal is made visible to a 
potential counterparty. This may include the deal maker's creditworthiness; that 
is their ability to settle the trade they are proposing. The chat server 60 handles 

20 the exchange of conversations between clients on the network. As will be 

discussed, conversational messages, which may or may not contain deal related 
information, are passed between clients via the chat server. A client can 
participate in several conversations at any given time and can conduct several 
different conversations with a particular other different client simultaneously, 

25 allowing two parties to have two or more deals under negotiation at the same 
time. 

Figure 3 shows the user interface which is displayed at each trader 
terminal. The display comprises a number panels. To an extent the panels 
displayed are configurable by each trader according to his or her preferences 
30 although some of the panels are permanent. In essence the display 100 includes 
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three notional containers 102, 104 and 106. Container 102 is the upper of the 
three containers and extends across the width of the display, beneath the upper 
container is a lower left container 104 and a lower right container 106. To the 
left of the containers is a configurable icon display 108. 

5 The upper container only displays panels which require the full width of 

the traders display area. Each of the panels which can be displayed is assigned 
one of two priorities. A panel with priority 1 may not be obscured. A panel with 
priority 2 may be covered or given zero height. In either circumstance the panel 
data model is maintained when the panel is invisible allowing the data contained 

10 to be displayed when they become visible again. 

There are three permanent panels each of which have priority 1. These 
are shown in figures 3 and 4. In the upper container 102 is displayed a deal stack 
110, in the lower left container 104 is displayed a conversations area 112 
containing a number of conversations in which the trader is participating, and in 

15 the lower right container is displayed an incoming conversations panel 114 in 
which incoming conversational messages are displayed. The incoming messages 
include conversations in which the trader is not yet participating, and may never, 
participate. 

The optional panels which the trader may choose to display include: 
20 A Trader Deal panel (not shown)* assigned a priority 1 and showing all 

the deals done by the trader and which may be displayed in either of the two 
lower containers; 

An Overview panel (not shown), assigned a priority 1 and positioned in 
either of the two lower containers; 
25 A Deal Log panel (not shown) having a priority 2 and showing deals 

logged by the system and displayed in the upper container 102; 
A Rates Area 116 which displays the current trading rates on the system for 
various currency pairs and which is assigned a priority 2; and 

A Conversation Archive (not shown) positioned in one of the lower 
30 containers and which has a priority 2. 
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As can be seen from figure 4, some of the panels include a button bar 
along their lower edge. The various functions of the buttons will be discussed 
below. The conversation panels button bars include a float button. Clicking on 
this button enables the position of the panel to be varied around the screen, even 

5 outside the window in which the entire system is displayed. This may be useful, 
for example, when the client wants to display several optional panels or there are 
a larger number of conversations open. In the embodiment described up to ten 
conversations may be ongoing at one time, although it will be appreciated that 
this is an arbitrary number which may be varied. 

10 The incoming conversations panel lists only incoming conversational 

messages. In the example of figure 3, there is a single conversation displayed. At 
this time, the client is not a party to the conversation. The conversation is 
displayed under four headings: ID, which is the unique conversation identity 
number; Time, which is the time at which the conversation was initiated by the 

15 counterparty; From, which is the identity of the counterparty initiating the 

conversation; and Message, which is the latest message line in the conversation. 
In the figure 3 example, the message A Conversation started by peter@GITQ ' 
has been sent by a trader identified as Peter at the institution having the identifier 
CITQ. The conversation was initiated at 13.34.54 and has the ID No. 1791. 

20 Each new conversation is identified with an ID No. It is also associated with a 
Deallnfo file which is a set of deal related information including the deal type: 
Spot FX, FX Outrights, Forwards etc.; the deal amount, the deal direction 
(maker, taker) and other necessary information. A Deallnfo structure also 
includes the current status of the deal. Central to the manner in which 

25 conversations are parsed is the concept of a deal being in one of a number of 
states indicating how far the deal has progressed. In essence, diese states begin 
with No State, which relates to conversation with no deal related information; 
RFQ which is die state in which a request for a quote has been identified by die 
parser; Quote, in which a quote has been identified by the parser in response to 
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the RFQ; and Buy/Sell in which the deal is completed by one party agreeing to 
buy or sell at the price quoted. 

Underneath the Incoming Conversations panel is a button bar with 
buttons marked Tick Up\ 'Clear', Transfer' and 'Chat'. To select a 

5 conversation for action the client clicks on the conversations line, which will 
cause that conversation line to be displayed in a different colour from any other 
conversations in the panel (in the present case it is the only conversation). If the 
client clicks on the Tick Up' button, a Conversation panel is opened in the 
bottom left container 104 for the selected conversation (Fig. 4). At this point 

10 the system causes all other parties to whom the conversational message has been 
sent to display the message 'username has joined the conversation'. When a 
party joins a conversation they see that conversation only from the point at which 
they joined it. Once a first person has picked up an invitation to chat to a deal 
code, that invitation will be withdrawn from all other parties to which the 

15 invitation was sent. 

Once a trader picks up a conversation, the conversation is removed from 
his Incoming Conversations panel. 

The 'Clear' button, when clicked, causes the selected conversation to be 
cleared from the display. When a conversation is cleared, the conversation 

20 initiator will receive a 'Conversation declined by username' in their own 
Conversations panel. 

The 'Transfer' button is only enabled if a conversation is bilateral. If 
clicked, the conversation will be transferred to the trader or Deal Code specified 
in the Transfer Conversation dialog. Rules may be established defining to 

25 whom, if anyone, a given trader may transfer a conversation. 

The 'Chat' button invokes the launching of a conversation session and 
also opens a conversation panel in the conversation area. Multiple conversations 
may be opened with the same person, although a warning box will preferably be 
displayed to notify the client if he is attempting to open a second or subsequent 

30 conversation with the same person. 
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All the functionality of the button bar may be displayed, alternatively, as a 
drop down menu to enable operation by keyboard only. 

Referring now additionally to figures 5 to 7, the deal stack shows a list of 
deals in which the trader is involved in and which are pending or completed. 

5 The Deal Stack 130 comprises the following major components: A Deal 

List 132, a Deal Detail Panel 134, and a Button Bar 136. The deal list presents 
information about a deal under four headings: the deal Status 120, the Time 
122, the Counterparty (Trader/Bank) 124, the Instrument which is being traded 
126 and the Deal 126 that is being made. The information presented in the deal 

10 list 1 32 is independent of the instrument being traded. This is achieved by the 
use of the deal detail panel and is extremely advantageous as it allows the deal 
stack to be presented to the client in a very simple manner, with the minimum 
amount of information and in a manner which is easily assimilated by the trader. 
To understand the text of the Deal field 126 it must first be appreciated 

15 how deal related information can be put into the system and how the system 
understands that information as relating to a deal. Deal information may be 
submitted to the system in one of two ways: direct deal jiiput or parsing of 
conversations. Parsing of conversations will be discussed in greater detail later. 
At this stage it is sufficient to appreciate that parsing involves the system 

20 analysing conversational messages to determine whether they contain any deal 
related content. If they do, then the deal is displayed in the deal list. 

A deal is commenced by a 'Request For a Quote' (RFQ) input into the 
system by a trader. An RFQ is an indication by a trader that he is interested in 
trading. The first line of die deal list in figure 3 shows an RFQ. Here, the trader 

25 has put a request out to die market to trade $2.5 Million in the US$/Canadian 
dollar market. At this stage no bid or offer prices are given and there is no 
indication whether trader wishes to buy or sell. The RFQ could have been input 
into the system as a conversational message or by the trader making a direct 
input, in which case he hits the RFQ button in the deal button bar. This will 

30 display a panel asking for the instrument, the currency pair and the amount. 
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Thus a deal may be initiated either by the entry into the system of a direct 
quote request or by the detection of a quote request by the parsing of 
conversations. For convenience the latter may be referred to as an indirect quote 
request. 

5 When an RFQ is received or detected, the system determines the text that 

will be displayed in the deal list. This will either be a transliteration of the direct 
RFQ or a representation of the parsed, indirect RFQ. 

A number of deal statuses are defined for each instrument. Each of these 
has an associated status string which is displayed in the Status field, a deal string 

10 which is the text displayed in the deal field and an understood description. 



Some examples of deal statuses for F/X Spot are as follows: 



Taker 


Maker 


Description 


Pre Submit-Taker 




RFQ is being transmitted t 
server. 


Pre Pickup-Taker 


Pre Pickup - Maker 


RFG has reached maker's 
screen. 


Pre Pickup-Taker 


Pre Pickup To Deal Code - 
Maker 


RFQ sent to a Deal Code 
has reached a member of tl 
Deal Code's screen. 


Pre Quote - Taker 


Pre Quote - Maker 


Maker has picked up 


Pre BuySell - Taker 


Pre BuySell - Maker 


Maker has submitted quot 


Pre Re-quote - Taker 


Pre Re -quote - Maker 


Maker has interrupted a 
quote from "Pre BuySell - 
Maker" 


Terminal Status 


Sold - Taker 


Bought - Maker 


Taker has bought 


Bought - Taker 


Sold - Maker 


Taker has sold 
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No Traders Available - 
Taker 




RFQ to deal code where nc 
traders are logged in 


Taker Cancelled 




Taker has cancelled from 
"Pre Submit -Taker" 


Taker Cancelled Pre Pickup 
*— Taker 


Taker Cancelled Pre Pickup 
- Maker 


Taker has cancelled from 
u Pre Pickup -Taker" 


Taker Cancelled Pre Quote 
— Taker 


Taker Cancelled Pre Quote 
-Maker 


Taker has cancelled from 
"Pre Quote - Taker" 


Maker Cancelled Pre Pickup 
-Taker 


Maker Cancelled Pre Pickup 
- Maker 


Maker cancelled from "Pre 
Pickup - Maker" 


Maker Cancelled Pre Quote 
-Taker 


Maker Cancelled Pre Quote 
- Maker 


Maker cancelled from "Pre 
Quote - Maker" 


Taker Cancelled Pre BuySell 
-Taker 


Taker Cancelled Pre BuySell 
-Maker 


Taker cancelled from "Pre 
BuySell - Taker"? 



The Deal Strings and Status Strings associated with some of the above are 
as follows: It should be appreciated that the deal string is the conversational text 
which is substituted by the system for the actual conversation entered by the 



trader or the substituted when the trader enters deal information either using the 
5 button bar on the deal stack or equivalent keyboard menus. 

Status String Deal String 

Taker Submitting I request 

~AMT~~CCYPAIR~ 

Taker Contacting I request 

~AMT~~CCYPAIR~ 

Maker Pickup? Can I quote 

- AMT — CCYPAI R~ ? 

Taker Contacting I request 

~AMT~~CCYPAIR~ 
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Pre Pick-up 

Pre Quote - Taker 

5 

Pre Quote - Maker 
Pre BuySell - Taker 

10 

Pre BuySell - Maker 
Pre Requote - Taker 
15 Pre Requote - Maker 
Sold - Taker 
Bought - Maker 
Bought - Taker 
Sold - Maker 



20 



Can I quote 
-AMT — CCYPAIR-? 
to Deal Code Maker 
Cpty quoting my 
~AMT~~CCYPAIR~ 
Can I quote 
~AMT~~CCYPAIR~? 
Cpty quoted 
-BIDOFR- 
for ~AMT~~CCY PAIR- 
Waiting Accept I quoted -BIDOFR- 

for -AMT- ~CCY PAIR- 
Re-quoting I request -AMT 

-CCYPAIR- 
Can I quote 
~AMT~~CCYPAIR~? 



Pickup? 

Accepted 
Quote? 
Buy/SeU? 



Re-quote? 
I sell 
I buy 
I buy 
I sell 



I sell at ~AMT~ 
~CCYPAIR~@~BID~ 
I seU at ~AMT~ 
~CCYPAIR~@~OFR~ 
I buy at ~AMT~ 
~CCYPAIR~@~BID~ 
I buy at ~AMT~ 
~CCYPAIR~@~OFR~ 
25 The following is an example of the deal statuses where the instrument is a 

Forward deal: 



Taker 


Maker 


Description 


Pre Pickup - Taker 




RFQ is being transmitted 






server. 


Pre Pickup - Taker 


Pre Pickup - Maker 


RFQ has reached maker's 






screen. 
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Pre Pickup - Taker 


Pre Pickup To Deal Code - 
Maker 


RFQ sent to a Deal Code 
has reached a member of tt 
Deal Code's screen. 


Pre Quote - Taker 


Pre Quote - Maker 


Maker has picked up 


Pre BuySell - Taker 


Pre BuySell - Maker 


Maker has submitted quote 


Pre Re-quote - Taker 


Pre Re-quote - Maker 


Maker has interrupted a 
quote from "Pre BuySell - 
Maker" 


S/B Pre Rate - Taker 


B/S Pre Rate - Maker 


Taker has Sold/Bought an* 
is waiting for Taker to ente 
spot rate 


B/S Pre Rate -Taker 


S/B Pre Rate - Maker 


Taker has Bought/Sold or 
Queried the Spot Rate and 
waiting for Taker to enter 
spot rate 


S/B Pre Confirm - Taker 


B/S Pre Confirm - Maker 


Taker has Sold/Bought an 
Maker has entered spot rat 


B/S Pre Confirm - Taker 


S/B Pre Confirm - Maker 


Taker has Bought/Sold an 
Maker has entered spot rat 


S /B Pre Rate 2 - Taker 


B/S Pre Rate 2 - Maker 


Taker has Sold/Bought, 
queried the Spot Rate and 
waiting for Taker to enter ; 
spot rate a second time 


B/S Pre Rate 2 - Taker 


S/B Pre Rate 2 -Maker 

/ 


Taker has Bought/Sold, 
queried the Spot Rate and 
waiting for Taker to enter : 
spot rate a second time 


S/B Pre Confirm 2 - Taker 


B/S Pre Confirm 2 - Maker 


Taker has Sold/Bought an 
Maker has entered spot rat 
a second time 


Terminal Statuses 


Sold/Bought - Taker 


Bought/Sold - Maker 


Taker has Sold/Bought an 
Confirmed spot rate 


Bought/Sold - Taker 


Sold/Bought - Maker 


Taker has Bought/Sold ar 
Confirmed spot rate 


No Traders Available - 
Taker 




RFQ to deal code where n 
traders are logged in 


Taker Cancelled Pre Submit 
- Taker 


Taker Cancelled Pre Submit 
- Maker 


Taker has cancelled from 
"Pre Submit - Taker" 


Taker Cancelled Pre Pickup 
- Taker 


Taker Cancelled Pre Pickup 
- Maker 


Taker has cancelled from 
"Pre Pickup - Taker" 


Taker Cancelled Pre Quote 
- Taker 


Taker Cancelled Pre Quote 
- Maker 


Taker has cancelled from 
"Pre Quote -Taker" 
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Maker Cancelled Pre Pickup 
-Taker 


Maker Cancelled Pre Pickup 
-Maker 


Maker cancelled from "Pre 
Pickup - Maker" 


Maker Cancelled Pre Quote 
-Taker 


Maker Cancelled Pre Quote 
- Maker 


Maker cancelled from "Pre 
Quote - Maker" 


Taker Cancelled Pre BuySell 
- Taker 


Taker Cancelled Pre BuySell 
- Maker 


Taker cancelled from "Pre 
BuySell - Taker 


Maker Cancelled S/B Pre 
Rate 2 - Taker 


Maker Cancelled B/S Pre 
Rate 2 - Maker 


Maker cancelled from "S/I 
i. re ivare z — l aj&er 


Maker Cancelled B/S Pre 
Rate 2 - Taker 


Maker Cancelled S/B Pre 
Rate 2 - Maker 


Maker cancelled from "B/; 
Pre Rate 2 - Taker" 


Taker Cancelled S/B Pre 
Confirm 2 - Taker 


Taker Cancelled B/S 
Confirm 2 - Maker 


Taker cancelled from "S/B 
Pre Confirm 2 - Taker 


Take Cancelled B/S Pre 
Confirm - B Taker 


Taker Cancelled S/B Pre 
Confirm 2 - Maker 


Taker cancelled from "B/S 
Pre Confirm 2 - Taker" 



For every deal in the deal stack there is a corresponding conversation 
session. In some cases, the RFQ will have originated from a conversation. In 
others it will have not. In the latter case, a direct quote, a conversation is created 
5 but a conversation panel is only opened, that is, the conversation is exposed, if 
specifically requested by the trader. 

Thus, whenever the system performs an action on a deal in response to a 
Trader action, a message line is included in the conversation session indicating 
the nature of this action. This message line is in a form where if the Trader had 
10 exposed the underlying conversation and typed in the message text it will parse 
and produce the same action on the deal. The Message will be in a form that 
reflects the best conversational practice from the point of view of parsing. 

The Deal List displays all live RFQs that the trader is involved with. He 
may see other RFQs if the appropriate options are set. The Trader will preferably 
15 have the option of clearing completed deals automatically as they are completed. 
The Trader will preferably have the option of seeing all RFQs that have been 
auto-forwarded from his account. Auto-forwarded RFQs shall be cleared from 
the Deal List by the Clear function. 

As mentioned above, the Deal List is wholly independent of the 
20 instrument being traded. Thus, the Deal List only displays five columns: Status, 
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Time, Trader/Bank, Instrument, and Deal. The Deal column contains an 
instrument/status specific string that is generated by the system to describe the 
deal. 

To balance the independence of the deal list 132, the Deal Detail Panel 
5 134 at the bottom of the Deal List has an instrument specific format and reflects 
full details of the deal that is currently selected in the list. 

When a new Deal is added to the Deal list it is inserted at the bottom of 
the list regardless of the currently selected sort order (a re-sort is used to position 
the deal correctly in the sort order). When a deal is added to the Deal List, as a 
10 result of the trader's actions (RFQ or Chat), the item last added to the table 
becomes the selected item. The list is scrolled so that the selected item is visible 
to the trader. 

If the new deal is initiated by a Counterparty the selected deal does not 
change. If focus is in the Deal List, the currently selected item does not change 
15 when a new deal is added to the list. If a new deal is added to the Deal Stack 
such that the Deal Stack would have to be scrolled to view the deal, then the 
scrollbar's background flashes, for example red, until the deal is made visible by 
scrolling. 

The Deal Detail panel may contain buttons and other controls diat relate 
20 to instrument specific functionality which is not available through the standard 
Deal Stack buttons. When a deal is in a modifiable state the modification is done 
via edit controls in the Deal Detail panel. These potentially modifiable fields 
shall have a different colour, for example, cyan, background to the rest of the 
deal Detail panel. The deal detail panel itself may be a different colour, for 
25 example yellow, than the deal list. When the fields arc editable theyjnay be 
distinguished, for example by a white background with a black border. 
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The Format of the Deal Detail panel is specific to the instrument of the 
deal. Every implementation of the panel has certain common fields and controls 
that are always in the same place: Status, Time, Trader/Bank, Instrument & 
Error/Warning Combo Box. Figure 5,6,8 and 9 illustrate the Deal Detail panel 

5 for F/X Spot in various stages of a deal and figure 7 illustrates the Deal Detail 
panel for F/X forwards at a certain stage of the deal process. 

Thus, the Deal Detail panel 134 includes all the information in the Deal 
list 132 except that instead of the deal list 132 it contains the information which, 
when entered and then parsed, will result in that deal list 132. Thus, for F/X 

10 Spot (Figure 5), the Deal Detail panel includes Amount, Currency Pair, Value 
Date, Bid and Offer prices and Dealt. In figure 5, the deal detail panel is shown 
for the first deal in the stack. This is a deal which has only just commenced and 
where the RFQ has been issued. As there are not yet any bid or offer prices, the 
only fields that are populated are the amount, the currency pair and the value 

15 date. When parsed this results in 'I request 2,5 Mil USD.cad' as shown in the 
top of deal list 132. 

In figure 6, the deal highlighted is the third in the list and, the status of 
the deal is pre quote B maker, indicating that the maker has picked up the takers 
quote and is quoting bid and offer prices for 3,200 million Japanese Yen. As the 

20 amount and the prices can both be edited, they appear in the Deal Detail panel 
as black text on a white background. 

Figure 7 shows the Deal Detail panel for a Forward deal. Here, the panel 
lists both near and far amounts, the currency, the nature of both the near and far 
deals, dieir value dates, the left and right hand sides, spot (Figure 5) amounts, all 

25 in amounts and deal amounts. In the example shown, the panel relates to the 
fourth deal in the list which is a completed deal. Thus, all the fields in the deal 
detail panel are populated and none is modifiable. In order that traders can be 
notified of unallowable entries or mistakes, there is an Error/Warning combo 
box in the lower left side of the detail panel. This combo box preferably has an 

30 entry in its drop down list for every error or warning condition associated widi 
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the deal. When an error or warning is selected in the combo box, the field to 
which the error or warning pertains will be highlighted in a very obvious manner, 
for example with a red (error) or orange background (warning). Errors and 
warnings are listed in the order of their priority. This combo box has an 

5 associated label to its right which indicates the number of errors or warnings that 
the combo box contains. When an alarm or warning condition is changed in the 
list, the highest priority item is the selected item. 

Figure 8 shows an example of the error box. Here, the highlighted deal is 
the third in the deal list. This requires both an amount and bid and offer prices. 

10 The trader has not entered bid and offer prices and the error box shows that a 
bid or offer price is required. In addition, the Quote? Status string is highlighted 
in red and the bid and offer fields which would normally be shown white. 

The presence of an error in the combo box shall disable keys and menu 
items, which allow the deal to proceed forwards, until the error condition is 

15 corrected. 

Figure 9 shows the deal detail panel for a deal that is waiting acceptance. 

Here, the maker has submitted a quote and the deal is now waiting for an 

acceptance or refusal from the taker. The amount, bid and offer details are 

highlighted to indicate that they can be modified. 
20 The Status, Time, Trader/Bank, and Instrument column entries are 

positioned on the Deal Detail panel exacdy beneath their respective columns in 

the Deal List. If the columns are resized, their relative positions will also change. 
The Error/Warning combo box and its associated count label will preferably 

automatically have its width set to that of the Status, Time, Trader/Bank and 
25 Instrument columns combined. The instrument specific fields beneath the Deal 

column will resize and position themselves proportionally to the width of the 

Deal column. 

The instrument specific fields will now be described in more detail for the 
two example instruments; It is to be understood that the invention is applicable 
30 to any instruments and the fields will vary from instrument to instrument. 
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The amount field is initially read only and displays the amount of the 
RFQ in millions. When the deal reaches the pre quote-maker stage (figure 6), 
the field becomes editable. 

The 'on' currency field is to the right of the amount field and is the 
5 currency in which the RFQ is expressed. If it is not the base currency it is 

displayed, if it is, then it is not displayed. It is not editable until the pre quote B 
maker stage at which point it becomes editable 

The currency pair field simply shows the currency pair being traded. 
The value date indicates the value date for the deal and cannot be change 
10 by the parties. It is a regular date for the instrument unless indicated otherwise, 
for example by an asterisk. 

The bid and quote fields display bids and quotes where these exist. They 
are read only except in the pre quote B maker and Pre re-quote maker stages of 
the deal when they can be edited, as described in relation to figure 6. If a big 
15 figure, that is the most significant digits of the price is available from the market 
feed into the trading system, that figure is used. If an arbitrage situation is 
present the market feed rate, the big figure from the system best offer is used. 
This can be seen in the system rates panel which the client may choose to display. 
The final field is the dealt price field which shows the price at which the 
20 deal was done. As can be seen from figure 10, this reflects the side (buy or sell) 
on which the deal was done. In figure 10, the dealt price is the bid price. 

The forwards specific fields shown in the deal detail panel are as follows; 
Near and Far Amounts. These function in the same manner as the 
Amount field in the Spot example. 
25 On Currency. This functions in the same manner as the Amount field in 

the Spot example. 

Currency Pair. This functions in the same manner as die Amount field in 
the Spot example. 



37743 v1;T4F01I.DOC 



WO 03/012588 



PCTYUS02/24021 



Near and Far Periods. If these periods conform to standard periods, for 
example one month, they will be shown as such. If they do not, they will be 
shown as broken. 

Near and Far Dates. This shows the near and far value dates. 

5 Left and Right Hand Side Prices. Where a LHS or a RHS exists it will be 

displayed in this field. It is a read only field except then the deal status is in pre 
quote B maker or pre requote B maker status. When in edit mode this field is 
pre-populated with the market rate, if available for the bid. If the LHS or the 
RHS is left blank by the trader, then a one sided price without a bid or offer, 

10 respectively, is quoted 

Premium and Discount. If the LHS is less than the RHS, the system 
assumes that the base currency is at a premium to the local currency. If the 
trader does not enter minuses and the RHS is less than the LHS, the system 
assumes that the base currency is at a discount to the local currency. Where a 

15 discount is detected, the system inserts A- A signs before each value and displays 
the bid and offer with them. A trader can enter negative amounts for a 
discount. 

Spot Rate. Where a spot rate exists, the Spot Rate Bid field displays it. It 
is a read only field except when the deal is in I B/S-Rate or I S/B-Rate (I 

20 sell/buy or buy/sell at a given rate) status. In edit mode, the field is pre- 
populated with a middle rate between the bid and offer market rates. 

Spot Button. As can be seen from figure 11, the deal detail panel includes 
a Spot button on which the client can click to display a spot rate query dialog 
window. The spot button is only visible to the trader when the deal is in I B/S 

25 B Confirm or I S/B - Confirm stages. The spot rate query dialog window 
includes an edit box, allowing the trader to enter text of up to 30 characters 
having been pre-populated with the text 'Check Rate'. This enables the trader to 
check the spot rate before committing to a deal. As can be seen from figure 11, 
the dialog box includes send and cancel buttons. The send button closes the 
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box, transmits the message and changes the deal status to I S/B awaiting rate or 
I B/S awaiting rate. 

When a maker deal receives a Spot Rate Query message against it the 
message appears as a warning in the error/warning combo box. This is 
5 illustrated in figure 12. 

All In Rate. This field is read only and, when the maker has submitted a 
spot rate, reflects the aggregate of the dealt rate and the spot rate. For 
Overnight or Tomorrow-Next periods, the sign of the forward bid or offer is 
reversed to calculate the all in rate. 
10 Dealt Rate. This is the final field in the deal detail panel and is a read only 

field. When the taker has Buy/Sell or Sell/Buy, the field reflects the price from 
the side of the market dealt on. 

Outrights. The fields for the deal detail panel when the instruments is an 
outright are not shown as they are the same as for a spot deal referred to above. 

15 The deal column displays different status dependent strings for each 

instrument. Some of these, for spot, were discussed earlier. The strings are not 
hard coded into the system but are configurable centrally by the system 
administrator. The traders preferably do not have control over the strings. As 
seen before, the status definitions comprise tokens, delimited by tildes (~) 

20 representing the underlying values for the deal. 

The tokens for spot and outrights are as follows: 



Token 


Value 


Format 


-TIME- 


Deal Time 


"hh:mm:ss M 


-TRADER- 


Trader 


As Deal Stack 


-BANK- 


Cpty bank 




-INST- 


Instrument 


As per deal stack 
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Token 


Value 


Format 


-AMT- 


Amount 


"9,999.9" + " " + ONCCT(if not 
base ccy) + " mil" 


— V>V_/ 1 A /vJ. JV~ 


C^cv nair 

V>V J W fill 


BASK local (On currency shall be in 
upper case.) 


-VALDAT- 


Value Date 


"dd mm yy" 


~BID~ 


Bid 


As per the Ccy pair specific format 


~OFR~ 


Offer 


As per the Ccy pair specific format 


-BIDOFR- 


Bid and 
Offer 


If Bid & Offer exist: Bid-Offerlf Bid 
only: Bid 

If Offer only: Offer- 

(Bid & Offer As per the Ccy pair 

specific format) 


-DEALT- 


Dealt Price 


As per the Ccy pair specific format 



The tokens for forwards deals are as follows: 



Token 


Value 


Format 


-TIME- 


Deal Time 


"hkmnKss" 


-TRADER- 


Trader 


As Deal Stack 


-BANK- 


Cpty bank 




-INST- 


Instrumen 
t 


As per deal stack 


-AMT- 


Amount 


•'9,999.9" + n .. + ONCCT(if not base 
ccy) + " mil" 


-HEDGE- 


Spot 
Hedge 


"9,999.9" + " " + ONCCY (if not base 
ccy) + " mil" 
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Token 


Value 


Format 


-CCYPAIR- 


Ccy pair 


BASE local (On currency shall be in 
upper case.) 


-NEAR- 


Near 
Period or 
Date 


As per deal detail panel 


-FAR- 


Far Period 
or Date 


As per deal detail panel 


-VALDAT- 


Value 
Date 


"ddmmyy" 


-BID- 


LHS 
Points 


As per the Ccy pair specific format 


-OFR- 


RHS 


As per the Ccy pair specific format 




T HS and 

RHS 

Points 


If LHS & RHS exist- LHS-RHS If 

LHS only: LHS 

If RHS only: RHS 

(LHS & RHS As per the Ccy pair 

specific format) 


-SPOT- 


Spot Rate 


As per the Ccy pair specific format 


-ALLIN- 


All In rate 


As per the Ccy pair specific format 


-DEALT- 


Dealt 
points 


As per the Ccy pair specific format 



The third part of the deal stack 130 is the button bar 136 which is 
beneath die deal list 132 and the deal detail panel 134. The button bar gives the 
trader various options for progressing or cancelling a deal. The button bar is 
5 specific to each deal. That is, the button bar displayed will depend on the deal 
which is selected in the deal stack. Some options will not be available to a trader 
at certain stages of the deal as will be explained. 
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Referring back to figures 5 to 8, it will be seen that the button bar differs 
from figure to figure depending on the status of the deal highlighted in the deal 
list. In some cases, buttons are not displayed in bold, indicating that they are not 
available. In some cases, buttons are substituted. As examples of the latter, the 
5 pickup button in figure 5 is replaced by a quote button in figure 6. The cancel 
button of figure 5 is replaced by the Nothing button in figure 6. 

The button bar provides the trader with an alternative, but equally valid 
method of trading to conversational exchanges with counterparties using the 
conversation panels. The system operates by converting deal instructions entered 
10 via the buttons into parsed text in the same manner as it parses conversational 
text to produce parsed text for the deal list deal field. 

The buttons available to traders are as follows: 

Pickup (e.g. fig. 5). This enables a trader to 'pickup' an RFQ entered 
into the system by a taker. As a result the pickup button is only available to the 

15 maker and then only when the deal is in the Pre Pickup B Maker status. By 

pressing pickup the maker indicates that he is interested in quoting on the RFQ. 
The RFQ may be sent by the taker to one or a number j>f traders. If it has been 
sent a deal code (that is a trading floor or floors), on receipt of a pick up, the 
RFQ will be removed from the deal lists of all other recipients. 

20 Quote (e.g. fig 6). This enables a trader to enter a quote and so is only 

enabled on the maker side when a deal is in the pre quote B maker status. The 
action of the quote will vary from instrument. For a spot or outright deal, the 
system transmits to the taker the makers bid and/or offer together with an 
amount. For a forward deal the system transmits to the taker the maker's LHS 

25 points and/or RHS points together with near and far amounts. 

The first button in the button bar combines all default actions. For the 
spot example, die button will revert to pickup but be grayed out for deal statuses 
other than those mentioned above. For forwards, more options are available. 
When the deal is in the status S/B or B/S Pre Rate - Maker or S/B or B/S Pre 

30 Rate 2 - Taker, the button will be displayed as a Rate Button (not shown) 
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enabling the maker to transmit to the system the makers spot rate. When the 
forward deal is in the status S/B or B/S Pre Confirm - Taker or S/B or B/S 
Preconfirm 2 - Taker, the button is displayed as a spot button which allows the 
Taker to accept the makers proposed spot rate. 

5 Chat. This button, which is only available when a single deal is selected 

causes the conversational panel opened for the deal to be displayed in the bottom 
left container. Even if the deal has been conducted in a direct not conversational 
form, the system will show a deparsed version of conversation that would have 
led to that deal state. This is possible as each deal has a conversation with it 

10 regardless of how the deal is being conducted, whether by conversation or direct 
entry using the button bars. The trader can switch to conversation at any time to 
continue the deal. The system will parse that conversation and will not 
distinguish between direct and indirect deal entry methods. In this respect the 
system is transparent. 

15 Hold. This button is only enabled when a selected deal is in Pre Quote - 

Maker status. It causes the selected deal to be put back into Pre Pickup - Taker 
and Pre Pickup - Maker statuses and, if the original RFQ was sent to a deal code, 
causes the RFQ again to be displayed to all those parties. 

Transfer. This button is only enabled when selected deals are in Pre 

20 Quote Maker Status. It enables a trader to transfer the deal to another trader 
within the limits of a preset authority. Pressing the button will cause a dialog 
box to be displayed into which the trader can enter the code of the trader to 
which the deal is to be transferred. A message to this effect is displayed on the 
originator's deal stack so he knows he is now dealing with a different 

25 counterparty. 

Sell. This button is only enabled for instruments such as Spot or 
Outrights. It provides a means for a taker to Sell at the Makers bid price and so 
is only enabled in the Pre BuySell status when there is a bid from the maker. 
RFQ. This button enables a Maker to put out a request for a quote to 

30 the market. When this button is pressed, the maker has to supply the amount 
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and the currency pair. On receipt of the RFQ by the system, a new conversation 
is associated with the deal. 

The RFQ button converts to the caption FIX when the RFQ has been 
initiated by conversational parsing on the Taker side and is awaiting confirmation 
for accuracy by the taker 

Callout. This button enables a trader to initiate a callout. 

Buy. This button is only enabled when a selected deal for an instrument 
such as a Spot or an Outright is in the Pre Buy/Sell - Taker status where there is 
an offer from the maker. By hitting the button, the taker indicates to the system 
that he wishes to buy at the maker's offer price. 

Cancel. This is a multifunction button whose caption will depend on the 
deal status and the instrument being traded in the selected deal. It is used for all 
negative functions. The functions will vary from instrument to instrument but 
for Spot are as follows: 



Caption/Action 


Taker Status 


Maker Status 


Cancel 


Pre Submit - Taker 
Pre Pickup - Taker 
Pre Quote - Taker 
Pre Re-quote - Taker 










Nothing 


Pre BuySell - Taker 


Pre Pickup - Maker 

Pre Pickup To Deal Code - 

Maker 

Pre Quote - Maker 
Pre Re-quote - Make 


Interrupt 




Pre BuySell - Maker 


Clear 


Any Deal in Terminal Status 


Any Deal in terminal Statu; 


Clear ( craved) 


If none of the above apply 


If none of the above apply 


The negative actions for forwards are as follows: 


Caption /Action 


Taker Status 


Maker Status 


Cancel 


Pre Submit - Taker 
Pre Pickup - Taker 
Pre Quote - Taker 





10 
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Pre Re-quote - Taker 




Nothing 


Pre BuvSell2-Taker 


Pre Pickup - Maker 




S/B Pre Confirm 2 - Taker 
B /o Pre Confirm z — l axer 
S/B Pre Rate 2 -Taker 
B/S Pre Rate 2 - Taker 


Pre Pickup To Deal Code - 
iviajs.cr 

Pre Quote - Maker 
Pre Re-quote - Maker 
B/S Pre Rate 2 - Maker 
S/B Pre Rate 2 - Maker 


Interrupt 




Pre BuySell - Maker 


Clear 


Any Deal in terminal Status 


Any Deal in terminal Status 


Clear (graved) 


If none of the above apply 


If none of the above apply 



Of the various actions mentioned above, the cancel action cancels the 
existing deal stage, reverting it to a preceding deal stage. The Nothing action 
indicates that the taker is not interested in a proposed deal. The interrupt action 
5 removes the deal from the deal stack and is only enabled when a deal reaches a 
terminal status, that is it is a completed deal. 

Clear All. This button clears all eligible deals from the deal stack. 

Off All. This button withdraws all deals that are in an appropriate form 
from the market. 

10 The foregoing section has described the trading actions that are available 

to a trader from the button bar. It is desirable that the trader can perform all 
available functions without using a pointing device such as a mouse. 
Accordingly, the system provides a set up pop up menus which provide the same 
functionality as the button bar but which can all be invoked from the keyboard. 

15 Each function can be invoked by the same keyboard character in each menu. 
Examples of the characters that can be assigned to functions are: 



Mnemonic 


Action 


A 


Clear All 


B 


Add Trader to Contact Book 
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Mnemonic 


Action 


C 


Chat 


F 


Fix 


H 


Hold 


L 


Add Trader to Caliout List 


M 


Contact Management 


O 


Off All 


P 


Pickup 


0 


Quote 


R 


RFQ 


S 


Sell 


T 


Transfer ^ 


U 


Caliout 


X 


Cancel, Nothing, Interrupt & Clear 


Y 


Spot Rate Query 


Z 


Sort 


xamplc of a possible menu for a deal status is as follows: 


Status 


Menu 


"Pre Pickup - 

Taker" 

(No Default) 


c. Chat F4 
f. Fix 
t. Transfer 
x. Cancel Esc 

a. Clear All Fl 1 (Only if deals to clear) 
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Status 


Menu 




o. Off All F12 




m. Contact Management (incoming only) 




r. RFQ F6 




u. Callout F7 




z. Sort 



2AESING 

The description above has been concerned with the traders interface with 
the dealing system. It has been mentioned that deals can be entered into the 

5 system directly through the deal stack button bar or equivalent keyboard strokes, 
or that deals can be entered conversationally, which conversation is parsed by the 
system to extract the deal related information. The next section examines the 
parsing mechanism. 

Parsing within trading systems is, itself, known. Parsing is used in the 

10 Reuters Dealing 2000/1 system referred to in the introduction. However, in 
that system, all deal transactions are through conversation. The trader does not 
have the option of using direct deal entry as described above. As a result there is 
no requirements for the system to be able to deparse deal information. Because 
of this, and for various other reasons, the parsing requirements of the present 

15 system differ markedly from those of the prior art. The following description will 
consider the foreign exchange markets and, in particular, the three instruments 
discussed above: FX Spot, FX Outrights and FX Futures. First, the manner in 
which the parser operates will be described by discussing how a conversational 
deal is executed with reference to the flow diagrams of figures 13, 14a, 14b and 

20 the various shots of the user interface of figures 15 to 22. It should first be 
noted that figures 15 to 22 show a different embodiment of the User Interface 
from that previously described. 

At all stages in the exchange of chat, the parser monitors the 
conversations looking for an RFQ (Request for a Quote). The presence of an 
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RFQ alerts the parser that a new deal is being initiated. Thus if two traders are 
exchanging pleasantries unrelated to a deal, the parser will monitor the 
conversation for an RFQ. The user's parser is responsible for parsing the user's 
conversation but plays no part in the parsing of conversation received from the 

5 other party to a conversation. 

In the following example, a new conversation has been initiated by a 
client referred to as Client 1 and shown in figure 15 as kdunay@EESN. This user 
has typed a message into his Chat panel and hit the return key. This causes the 
User Interface (Figure 2) to send the line of chat to the parser regardless of 

10 content. The parser parses the conversation looking for a change of status and 
for other deal related information. In the present case, the parser has detected an 
RFQ in the line of chat. That line, although not shown may have been 'I want 1 
Yen'. The parser detects this as an RFQ and then looks for other deal related 
information which includes the instrument traded, here identified as FX Spot, the 

15 currency pair, here US Dollars/Japanese Yen, and the amount, here 1 Million. 
The Parser returns the parsed conversation to the User Interface in the form of 
the Deallnfo structure referred to earlier and which contains the Deal Status and 
the deal related information. 

Figure 15 shows the situation were the Deallnfo structure has been 

20 returned to the User Interface. The RFQ has not yet been entered into the 

system and is displayed as a parsed line 200 in the deal stack 202. The parsed line 
can either be cancelled by the user, Mnna y@EBSN T by hitting the Red Cancel 
button 204 or edited, for example to change the amount or the currency if the 
trader has made a mistake, changes his mind or is reacting to a change in the 

25 market conditions. Editing is performed by pressing the 'Fix' button 208. 
Alternatively, the user may re-enter the conversation so that it is reparsed. To 
indicate to the user that action is required, the Status of the line in the deal stack 
is preferably shown in a representative colour, for example green. The button 
206 on the button bar that the user has to press for the RFQ to be sent is also 

30 shown in Green. The parsed conversation is shown in the deal stack in a 
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representative colour, for example red, to show that it is system generated text. 
At this point, a system message 'Submit?' is also displayed, in red, in the 
conversation panel. 

It will be seen that the deal stack of figure 15 differs from that of the 

5 earlier example in that it includes a strip 210 above the button bar which displays 
to the user, significant information about a highlighted deal. Thus the strip 
includes the deal status 201, the trader 203, the instrument (spot) 205, the 
currency pair 207, the amount with the base currency indicated and the buy and 
sell rates. These latter rates are displayed in boxes 212, 214 which are unfilled in 

10 figure 15 as no rate has yet been quoted in this deal. 

In the example, the line of conversation parsed resulted in a detected deal 
status. The line of text could simply have said something like 'Hi, how are you 7 . 
The parser would not have detected any deal related information but it would 
still send a response to the User Interface to indicate that a line of conversation 

15 had been parsed, but no dealing information had been found. 

When the user is satisfied with the parsed line as it appears in the deal 
stack, he presses the 'Proceed 7 button 206. This causes the parsed conversation 
to be sent to the client's communications module 22 (Fig. 2) and then to the 
deal server 28. 

20 At this point there are a number of features of the parsing which should 

be emphasized. First, the parser parses the conversation line by line and parsing 
does not take place until the user has finished typing and hit the send button 
216. This contrasts with the system used in the Reuters 2000/1 system referred 
to earlier which parses conversations line by line as they are being typed by the 

25 user. The system described here is advantageous in that the user can change 
what he has typed, for example to react to changes in die market, or simply to 
correct errors, without disclosing his hand to the counterparty trader. Giving the 
counterparty trader knowledge about a view of die market is highly undesirable 
as it may affect the bid or offer he makes. 

30 Second, the parser plays no part in die deal making process and retains no 
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knowledge of the deal. The parser merely looks at the line of conversation for 
information relating to the deal status. It returns the Deallnfo structure to the 
User Interface and does not retain any knowledge of the deal. This makes the 
parser very simple. 

5 Third, the parsing is based on a deal status structure with the emphasis on 

detecting status movements. The deal status are very simple: None, RFQ, 
Quote, Buy/Sell although these are elaborated as will be discussed. In each of 
the statuses, there are a number of deal related terms that the parser looks out 
for. This makes parsing very simple and accurate. Firsdy because there are not 

10 many terms to look for and secondly because there is less chance of confusion 
arising resulting in misparsing. This could occur, for example, if a line of 
conversation referred to a historical deal between the parries. By separating the 
deal process into a number of statuses each of which have a limited number or 
parseable terms, it is relatively easy for the parser to avoid such misparsings. The 

15 details of the statuses and dealrelated terms for each status will be discussed in 
detail later. 

In the example given, the conversation parsed by the parser contained 
both a change in deal status and all the information that is required to 
accompany that detected status (instrument, currency pair, etc.). For each of the 

20 possible deal statuses there are only a number of permitted transitions and for 
each deal status there is a limited number of expressions that the parser will 
recognize as indicating a change in status. For example, if the new conversation 
includes a request for a quote, the parser will look for information which 
indicates a quote. It will parse the entire line and, for a given status will look to 

25 fill a predetermined number of information fields. These will vary depending on 
the status. As an example, when the parser is expecting a change in status from 
RFQ to Quote, it will look to see whether there is an indication of a bid quote 
and/or an offer quote, or a refusal to quote. If there is a bid/offer quote it also 
looks for an indication of the currency, in the case of an FX spot trade. The 

30 states of the deals and the fields required will vary depending on the instrument 
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being traded. 

Once the conversation input from the user has been parsed, the parser 
returns to the user interface one of three possibilities: 

a) there is nothing in the conversation that is parseable. This will be 
5 the case is the conversation does not include any deal related 

information; 

b) an update in the deal structure which includes the new deal status 
and the fields found; 

c) an error message where there is an ambiguity and it cannot 

10 resolve the status change. In this case, the error is displayed in the 

chat stack and the deal is not changed. 
Reverting back to the parsed conversation message. From the client's 
communications module 22 the message is sent to the deal server 28 at which 
point it is checked to ensure that it conforms with system regulations, banking 

15 regulation and business related rules. It may also enable credit checks to be 
made, for example by linking in the deal details to the user bank's global credit 
checking mechanisms. If the deal cannot proceed a faihyre message is displayed 
at the user terminal but the counterparty is not made aware of that fact. As far as 
the counterparty is concerned, the RFQ that he put out is simply not answered. 

20 This ability to conceal failed deals is advantageous as a user will often not want a 
counterparty to know that he has tried to deal with him but failed. He will also 
not want that counterparty to know the details of the attempted deal as it will 
disclose to him valuable information about his intentions and his reading of the 
market. This advantage stems from the manner in which die system parses 

25 conversations on a line by line basis rather than in real time as they are typed in 
character by character. 

Assuming that the deal server 28 does not reject die RFQ, the parsed 
message is sent to the destination User Interface via the destination client's 
communication module. It should be noted that the system is arranged such 

30 that the deal server handles all deal related, parsed traffic and the conversation 



37743 v1;T4F01I.DOC 



WO 03/012588 



PCT/US02/24021 



server handles all conversations carrying unparsed conversation; that is 
conversations which the parser has not found to contain a change in deal status. 
This dual server arrangement is convenient but is not essential and could be 
replaced by a single server or some other server configuration. 

5 Figure 16 shows the user interface after the RFQ has been sent to the 

counterparty. The status of the deal in the deal stack is shown as 'waiting pick 
up' meaning that the User Interface has not been notified that that the 
counterparty has picked up the deal from his incoming conversations panel. In 
the conversation panel for the deal, the client's conversation is now shown in a 

10 representative colour, for example green, to show that the message originated 
from the client. 

Referring now to figure 17, there is shown the user interface of the client 
to whom the RFQ described in figure 14 has been sent. The client is identified 
as test@EBSN . The RFQ message has been passed by the deal server and relayed 

15 to client rest@RBSN . The sending client User Interface has also been notified 
that the message has been sent. The incoming message will first appear in the 
client's incoming messages panel. In figure 15, client test@EBSN has doubled 
clicked that message to open up a new conversation in the active conversation 
panel. In the figure this is identified as conversation with the name of the 

20 counterparty, IrHnna yOEBSN identified. The system indicates in the conversation 
panel that client rest@EBSN has joined the conversation and displays the parsed 
message in the deal stack. Note that the message is identified as Quote 1 mil JPY 
usd/JPY> which is an embellished version of the parsed message displayed in the 
maker client's deal stack. The original version of the message is shown in die 

25 conversation panel. The message is shown in the conversation panel in a 
representative colour/for example blue, to indicate that it is an incoming 
message. In the deal stack, die status of the deal is shown as 'pickup' and 
coloured green indicating diat action is required by the client. In diis case die 
client has to respond to the RFQ. 

30 The second client, rcst@EBSN then types in his response to the RFQ in 
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the chat line 220 of the conversation panel and hits the send button 222. In the 
same manner as the RFQ line, this causes the User Interface to send the 
complete line of text to the parser which again parses the text and sends back the 
Deallnfo structure to the User Interface. The parsed text, if it contains a change 

5 of status and the necessary deal related information is sent via the deal server to 
the counterparty. It should be noted that the parser for client kdunay@EBSN 
only parses conversation entered by that client and the parser at client 
rest@EBSN only parses conversation entered by that client. 

Figure 18 shows the counterparty client test@EBSN when a quote has 

10 been entered by the user and parsed by the parser but not confirmed by the user. 
The status in the deal stack shows Quote? and the conversation panel indicates 
the quote as parsed by the parser followed by a question mark. The chat line of 
the conversation panel invites the user to proceed. In figure 18, the status in the 
deal panel is preferably shown in a representative colour showing a warning, in 

15 this case orange. The system displays a message in the conversation panel 'Big 
figure unavailable'. In this case the message is false and was generated as the 
rates panel was disabled but serves to illustrate how warnings can be shown. 

Figure 19 shows client kdnna y@EBSN's user interface when the response 
is received. Client resr@FBSN has submitted a quote in response to the RFQ 

20 shown as 123.33/123.45. These figures arc the buy/sell spread. This is shown 
in the conversation panel in e.g., blue as it is an incoming message. Note that 
the previous entry in the panel is the client's own conversation. This is shown in 
a representative colour, for example green. The deal stack shows the change in 
Status to Buy/Sell, highlighting the status in green. This shows that action is 

25 required by the client and that the next phase of the deal is either an agreement 
to buy and sell at the offer price or a denial. It can be seen that the deal 
information line shows the offer prices, the amount and the currency pair and 
that the large boxes on die bottom strip 212, 214 now include die buy/sell 
prices. 

30 Figure 20 shows the first client's interface after that client has replied to 
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the quote by agreeing to sell at the offer price. The status has changed to I sell 
and the deal line now reads l I sell 1 mil JPY usd/JPY ©123.33. The last line in 
the conversation panel shows, in green that the client has sold and is preceded by 
a system prompt, in red, Sell? This prompt appears when the user types in 4 SelP 
5 and the change in status to sell is detected by the parser and returned to the User 
Interface but before the client has confirmed the sell by hitting the proceed 
button. 

No matter what the status of a deal, the parser always looks for new RFQs 
and, if one is detected, opens a new conversation. Thus, in the previous 

10 example, instead of agreeing to sell, the client kdunay@EBSN could have put in a 
new request such as l I want 1 mil gpb' indicating that he wants to buy one 
million £Sterling against $US. The parser detects this RFQ and opens a new 
conversation but does not terminate the existing conversation. Then there are 
now two conversations between the same two parties. The ability to run several 

15 conversations between the same two counteparties simultaneously is highly 

desirable. The system can support a large number of simultaneous conversations 
between the same two counterparties, for example 10. This should not be 
confused with the ability to have a number of conversations open with different 
counterparties at the same time which is known in the art and also possible with 

20 the system embodying the invention. 

The above discussion illustrates how the system handles a conversation 
input by the user. In the course of a deal there will be several lines of 
conversation, with each handled in the manner discussed. As soon as a parser has 
passed on the deal structure and the fields detected to the user interface, the 

25 information is lost from the parser. The parser preferably has no capacity or 
requirement to retain information regarding the history of the conversation. 

Figures 21 and 22 illustrate two further aspects of die parser. In figure 21 
it can be seen diat there are two separate conversations between t est@EB$N and 
kdnna y@EBSN . The two conversations are shown at 224 and 226 in die deal 

30 stack and as conversations 1 and 2 in the conversation panel. In figure 21, the 
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second conversation is active. This is the top line of the deal stack. The system is 
returning an error message as the quote has been input without an amount. The 
quote status is indicated in a representative colour, e.g., pink, in the deal stack 
and an error message is displayed in red above the button bar telling the user the 
5 source of the problem. In this case it says 'must have amount'. The error is also 
reflected in the conversation panel which has a series of error messages 'Amount 
required' 228 followed by a further, more emphatic, message 'must have 
amount' 230 

Figure 22 gives another example of the warning message. The situation 
10 illustrated is a development of the second conversation of figure 21. A quote 
amount has now been entered but the system is again indicating that the big 
figure is unavailable and so highlights the status in orange. The second deal line 
in the deal stack is also showing a warning as the deal has been withdrawn by one 
of the parties. 

15 Turning back now to figures 13 and 14. Figure 13 shows an overview of 

the process described. At step 300, the parser looks to see if there is an 
identification number for a given conversation. If there is not, at step 302 it 
creates a new deal info structure and, at step 304, sets the status of the deal to 
Ano deal®. If there is an ID, it looks up the deal status at step 306 from the 

20 previous parse. However, this status is not held at the parser but is provided from 
the user interface. At step 308 the current deal status is set to the next stage in 
the deal and at step 310 definitions are applied to the message according to the 
current deal status. These determine which terms in the conversation the parser 
will acknowledge as being deal related information. 

25 In Figure 14A and 14B, the trader inputs a message to the user interface 

at step 400. This message is sent by the user interface to the parser where it is 
received at 410. At 420 the parser attempts to parse the message. If it cannot be 
parsed, the conversational message is sent to the chat server at 430 and then to 
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the intended recipient at 440. A message that cannot be parsed is one that has no 
deal related content. 

If the parser can detect deal related information, at step 450 it determines 
whether or not there is an error. If an error is detected an error message is sent to 
5 the trader at 460. 

If there is no error, at step 470 the parser determines whether or not 
parsing is complete. If it is not, the client is asked to complete the information at 
step 480. 

If parsing is completed successfully, at step 490, the deal information file 
10 is updated and, at step 500, the parsing results are displayed at the user interface. 
The trader must then decide whether or not they want to proceed and 
send the parsed message to the counterparty (at 510). The confirmation stage is 
performed by the proceed, edit and cancel buttons on the deal panel described 
previously. In the simplified diagram of Figure 14B, the edit function is not 
15 shown. If the trader does not want to proceed, the deal is cancelled at step 520 
without having been shown to the counterparty. If the trader does want to 
proceed, at 530 the parsed message is sent to the deal se/ver and at 540 the deal 
server tries to confirm the parsed message against the system business rules. If it 
cannot confirm the deal at step 550 the trader is informed but the counterparty 
20 trader receives no indication that the message was ever sent. If the deal is 

confirmed then a confirmation message is sent to the trader at 560 and also to 
the chat server at 570 and onto the recipient at 440. 

The manner in which parsing takes place will now be described in more 

detail. 

25 A general FX terminology module provides an indication of the common 

terminology used by dealers to deal FX via the Chat panel on the Trader 
platform. 

The system monitors all conversations conducted via the chat panel and 
interprets text from the conversations into a fixed format within the deal stack, 
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thus standardizing the deal details and enabling the system to construct a formal 

deal ticket for each FX deal. 

The system can distinguish the important terms within a conversation that 

relate to the completion of the deal. This includes terms related to requesting a 
5 quote, responding with a quote, confirmation of buy or sell, and any notice of 

special setdement instructions. 

The system can distinguish terms within a conversation that could lead to 

ambiguity as to deal details or whether a deal is in progress at all. For instance, 

dealers may be discussing a previous trade or providing indicative quotes 
10 internally. 

The system can ignore terms that are not pertinent to the completion of a 
deal. That is, friendly formalities such as discussions regarding the weather or 
particular news stories, will be overlooked by the system, no matter at what point 
in the deal process, they occur. 
15 Functional Components of the General FX Terminology Requirements are: 

Chat Terminology - Common Deal Terms 
Chat Terminology - Negative Terms 
Chat Terminology - Unrecognized Terms 
The interaction between components is: 
20 Chat Terminology - Common Deal Terms provides the list of 

terms and variables that are direcdy pertinent to an FX deal 
being completed and should be parsed by the system. 

Chat Terminology - Negative Terms provides the list of negative 
terms that the system should be aware of diat would 
25 indicate that preceding/proceeding terms/phrases are not 

pertinent to a deal in progress. 
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Chat-Terminology - Unrecognized Terms describes how the 
system should treat terms/phrases it does not recognize 
within the chat conversation. 
Chat Terminology - Common Deal Terms 

5 The system can recognize all common phrases and terms used within a 

conversation that are pertinent to the completion of the deal. Specific terms 
within the conversation provide values for the variables that are necessary for a 
deal to be concluded. The system should be able to pick up these terms and to 
deliver the data to the corresponding fields within the deal stack. 

10 Dealers use a variety of different ways/shortcuts to communicate the same 

thing within a conversation. The system can pick up on market conventions in 
relation to the key variables required for the deal stack. 

As part of a request for quote, the system permits the user to enter a single ISO 
currency code 'CurrX' or its pseudonym to represent the currency pair 
15 USD/CurrX. For example: 

CHF = USD/CHF 

NZD - NZD/USD 

GBP = GBP/USD 

Cable = GBP/USD 
20 Peso = USD/MXP 

The system permits die user to enter a complete currency pair, i.e. reference to 
bodi currencies, in the following formats: 

Currencyl/currency2 
Currencyl Currency2 
25 Currencyl Currency2 

Currencyl -Currency2 
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The system permits the user to specify an amount with a label to denote 
magnitude. For example: 

10 mio = 10 million 

500k = 500 thousand 

5 lbio = 1 Billion 

If the user specifies an amount without a label that denotes the magnitude, the 
system shall interpret the amount as being expressed in millions. For example: 

10 o 10 million 

CHF in 20 » USD/CHF for 20 million USD 

10 GBP in 500k = GBP/USD for 500,000 GBP 

The system permits the user to specify a two-way quote in any of the following 
formats: 

bid quote/offer quote 

bid quote-offer quote 
15 bid quote offer quote 

bid quote *offer quote 
The user may specify a one-way bid quote in any of the following formats: 

Bid quote/- 

buy at [Bid quote] 
20 Bid at [Bid quote] 

The user may specify a one-way offer quote in any of the following formats: 

-/Offer quote 

sell at [Offer quote] 

Offer at [Offer quote] 
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The user may confirm a deal with the following terms: 
ok 
done 

confirmed 
5 conf 
agreed 
agree 

The system permits the user to cancel a deal using any of the following terms: 
Cancel 
10 Cane 

Nothing 
Nothing 

Nthing , 
Nthng 
15 NT 

No Thanks 
No thks 

If the user cancels the deal in the conversation, the system automatically cancels 
die appropriate deal entry in the Deal Stack. 
20 Chat Terminology - Negative Terms 

The system takes into account that dealers on the system may discuss 
previously completed deals via the chat panel, but are not attempting to 
complete a deal. The system will recognize terms that indicate diat the current 
conversation in which the dealers are engaged, does not pertain to a deal. 



37743 vl : T4F01i.DOC 



WO 03/012588 PCT/US02/24021 



The system does not attempt to parse any variables from the chat panel if 
the variables are preceded by the following phrases within the same line of 
input/sentence, that indicate a past event (substitute any characters for . . . ) : 

did [deal variables] 

5 dealt [deal variables] 

completed [deal variables] 

made [deal variables] 

quoted [deal variables] 

bought [deal variables] 

10 sold [deal variables] 

Some examples of the incidence of the above terms are as follows: 

We did 10 mio EUR ystd - The dealer is referring to a historical 
deal 

We dealt cable in 10 last week - The dealer is referring to a 
15 historical deal 

I completed the stg deal - The dealer is referring to a historical deal 
He made me stg at 67/70 B The dealer is referring to a historical 
quote 

I have done a deal for Swiss in 20 - The dealer is referring to a 
20 historical deal 

He quoted 67/70 - The dealer is referring to a historical quote 

If the user has input phrases/terms pertaining to a past event the system 
continues its monitoring process of the chat panel immediately after die input 
has been sent to the counterparty. For example: 

25 We did Eur yesterday 
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I want 20 CHF today - the dealer first refers to a historical deal, 
which is ignored by the system based on the rules above. The 
second sentence is an RFQfor USD/CHF, 20 million USD 
that will be parsed by the system. 

5 I did not quote you CHF at 50/57 

Its 60/57 - The dealer first refers to a historical quote (or a 

mistaken quote in this case) which is ignored by the system 
based on the rules above. The second sentence is a quote for 
USD/CHF that will be parsed by the system. 

10 Chat Terminology - Unrecognised Terms 

The chat panel is used for a variety of casual conversations that have no 

bearing on the dealing process. The system will ignore all terms that do not 

conform to requirements of the Deal Use Case. 

FX SPOT PARSING 
!5 The FX Spot module provides the user with the ability to deal the FX 

Spot instrument type via the Chat panel on the EBS Trader platform. 

The Functional Components of the FX Spot Parsing Requirements are 
the Deal Use Case and the Chat Terminology - Deal Terms. The Deal Use Case 
describes the process of completing a deal and enables the system to actively 
20 'watch' for particular terms/phrases it is expecting to see within a conversation 
that are pertinent to an actual deal. Chat Terminology - Deal Terms provides 
the list of terms and variables that are direcdy pertinent to a deal being 
completed and should be parsed by the system. 
Deal Use Case 

25 In order to complete an FX spot deal, the following must take place: 

An FX Spot request for quote is sent by a taker to his maker(s). 

In response, the maker can either: provide a two way quote (bid and 
offer) in response to the RFQ - this is only if an amount was indicated in the 
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RFQ; provide a one way quote (bid or offer) in response to the RFQ - this is 
only if an amount as indicated in the RFQ; provide a quote for a particular 
amount in response to the RFQ; or indicate that he does not want to supply a 
quote, so no deal takes place. 
5 The taker receives a quote. In response he can either: indicate he wants to 

buy and confirm the deal; indicate he wants to sell and confirm the deal; or 
cancel the deal if the taker does not like the quote. 

The deal is now complete. 

The system recognizes the stage at which an FX Spot deal is at within the 
10 dealing process. The system watches for particular phrases pertinent to the 
particular stage of the deal process. If no deal is currently in progress within a 
chat panel, the system monitors the chat panel for indications of a request for 
quote. In particular, the system watches for the following terms that indicate a 
request for quote has been initiated within a chat panel conversation: 

15 An indication of the instrument type (FX Spot) 

An indication of a currency pair 

An indication of an amount 

An indication of the currency of the amount 
A request for quote includes at least an indication of the currency pair. Some 
20 examples are as follows: 

hihi CHF pis - The taker is requesting a quote for USD/CHF 

hi CHF in 10 pis - The taker is requesting a quote for USD/CHF for 
10 million USD 

Hihi SPOT STG in 10 pis - The taker is requesting a quote for 
25 GBP/USD for 1 0 million GBP 
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Hi frd GBP/EUR pis - the taker is requesting a quote for 
GBP/EUR 

Welly for 20 pis - the taker is requesting a quote for NZD/USDfor 
20 million NZD 

5 The system parses all variables indicated as part of an RFQ from the conversation 
to the appropriate field in the Deal stack. 

If the system has identified a request for quote, and it has been sent to the 
maker, the system monitors the chat panel for indications of a response to the 
request for quote. The system watches for the following terms within the chat 
10 panel that indicate a response to the request for quote: 

indication of a bid quote 

indication of an offer quote 

indication of a refusal to quote 

an indication of an amount 

15 an indication of the currency of the amount 

A response to a request for quote includes an amount if one is not supplied in 
the RFQ, together with at least one of the following: 

a bid quote 

an offer quote 

20 OR 

a refusal to quote 
Some examples of a response to a request for quote: 

1.4696/4700 - The maker provides a two way quote } bid/ offer 
4696/4700 - The maker provides a two way quote bid/offer 
25 96 /00 - the maker provides a two way quote bid/offer 
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56-60 up to 10 - the maker provides a two way quote, bid/offer, and 
an indication of amount, 10 million 

I buy at 60 - the maker provides a one-way quote; the offer quote. 
Nothing - Maker refuses to quote 

5 The system parses all variables indicated by the maker in the response to a 

request for quote from the conversation to the appropriate fields in the Deal 
Stack. A refusal to quote is indicated if the maker inputs this intention into the 
chat panel or cancels the deal through the deal stack. If the maker refuses to 
quote, the system shall conclude that the deal has been cancelled. If the maker 

10 refuses to quote, the system re-starts its monitoring process and looks for a 

request for quote within the conversation. The system ensures that the following 
variables have been parsed from the conversation to the deal stack prior to permit 
the taker to indicate his intention to buy or sell: 

The currency pair 

15 The amount 

z 

The currency of the amount 
A bid and/or an offer 
If the above variables have not all been successfully parsed to the deal 
stack, the system requests that the maker input the missing variables prior to 
20 indicating his intention to send. For example, the system could raise an alarm. 
If the system has identified a response to a request for quote, and the response 
has been sent to the taker, the system monitors the chat panel for a response to 
the quote. 

The system watches for the following terms within die chat panel that 
25 indicate a response to the quote: 

an indication to buy at the offer price 
an indication to sell at the bid price 
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an indication of a cancellation of the deal 
A response to a quote includes at least one of the following: 
an indication to buy at the offer price 
an indication to sell at the bid price 
5 an indication of a cancellation of the deal 

Some examples of a response to quote are: 

Ok, I buy - the taker is happy with quote and agrees to buy at offer 
price 

Ok, mine in 10 - the taker is happy with quote and agrees to buy at 
10 offer price for an amount of\Q million, the amount "10" is 

ignored by the system, the whole available amount is bought 

Yours - the taker is happy with quote and agrees to sell at the bid price 

Ok I sell - the taker agrees to sell 

Nothing thks - the taker does not like the quote and does not wish to 
15 deal 

A cancellation of the deal indicated if the taker inputs his intention to 
cancel (he does not like the price) or the taker cancels the deal within the deal 
stack. If the taker cancels the deal, the system shall re-start its monitoring 
process and look for a request for quote within the conversation. If the system 
20 has identified a response to quote the system confirms the deal in the deal stack 
and re-starts its monitoring process and look for a request for quote within the 
conversation. 

Chat Terminology B Deal Terms 

The system can recognize all phrases and terms used within a conversation 
25 that are pertinent to the completion of the deal. 
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Specific terms within the conversation provide values for the variables that 
are necessary for a deal to be concluded. The system is able to pick up these 
terms and to deliver the data to the corresponding fields within the deal stack. 

Dealers use a variety of different ways/shortcuts to communicate the same 
5 thing within a conversation. The system can pick up on market conventions in 
relation to the key variables required for the deal stack. 

As part of a request for quote, the system permits the user to enter the 
term "spot" to indicate that the deal is a FX Spot deal. For example: 
SPOT Swiss please = FX Spot deal for USD/CHF 

10 As part of the request for quote, the system permits the user to specify a 

currency pair with or without an amount, to indicate that the deal is a FX Spot 
deal. For example: 

Stg pis - FX Spot deal for GBP/USD 
EUR pis - FX Spot deal for EUR/USD 
15 Eur in 10 pis = FX Spot deal for EUR/USD, amount is 10 million 

EUR 

CHF for 20 = FX Spot deal for USD/CHF, amount is 20 million 
USD 

The system permits the user to specify an amount of currency to buy or 
20 sell. For example: 

10 mio GBP against USD pis = USD/GBP, 10 million GBP 
Eur pis, 10 million US - EUR/USD, 10 million USD^ 

If the user does not specifically indicate the currency of the amount, die 
system shall interpret the amount to represent the amount in the base currency 
25 of the currency pair. For example: 

eur in 10 pis = EUR/USD 10 million EUR 
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chf for 10 = USD/CHF, 10 million USD 

50 mio Welly pis = NZD/USD> 50 miUion NZD 

The system permits the user to enter the big figure only once as part of 
the first part of the quote, be it bid or offer. For example: 
5 1.4567/70 -> bid quote « 1.4567, offer quote = 1.4570 

121.43/53 => bid quote = 121.43, offer quote = 121.43 

The system permits the user to enter a quote without the big figure, i.e. 
only the pips of the quote. For example: 

67/70 => GBP/USD quote, bid quote - 1.4567, offer quote - 
10 1.4570 

43/53 => GBP/JPY quote, bid quote = 121.43, offer quote - 
121.53 

The system warns the user if there is no big figure available. The system 
permits the user to indicate his preference to buy the stated amount of currency 
15 by using the following terms: 

Buy 

Mine 

M 

B 

20 Take 
T 

At [Offer Price] 
[Offer Price] 

The system permits the user to indicate his preference to sell the stated 
25 amount of currency by using the following terms: 
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seU 
Yours 
Y 
S 

5 give 
G 

At [Bid Price] 
[Bid Price] 

The system permits the taker to indicate his intention to buy or sell. For 
10 example: 

I sell CHF = User sells previously indicated amount of CHF 

Y = User sells previously indicated amount in previously indicated 
currency 

FX OUTRIGHTS 

15 The parsing requirements for FX outrights are similar to those described 

for FX Spot. 

The following is a description of the process followed to complete an FX 
Outright deal 

An FX Outright request for quote is sent by a taker to his maker(s). 

20 In response, the maker can either: provide a two way quote (bid and 

offer) in response to the RFQ - this is only if an amount was indicated in the 
RFQ; provide a one way quote (bid or offer) in response to die RFQ - this is 
only if an amount was indicated in the RFQ; provide a quote for a particular 
amount in response to the RFQ; or indicate that he does not want to supply a 

25 quote, no deal takes place. 
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The taker receives a quote. In response he can either: indicate he wants to 
buy and confirms the deal; indicate he wants to sell and confirms the deal; cancel 
the deal B the taker does not like the quote. 

The deal is now complete. 
5 The system recognizes the stage at which a deal is at within the dealing 

process and watches for particular phrases pertinent to the particular stage of the 
deal process. If no deal is currently in progress within a chat panel, the system 
monitors the chat panel for indications of a request for quote. The following 
terms that indicate a request for quote has been initiated within a chat panel 
10 conversation are watched for: 

An indication of the instrument type (FX Outright) 
An indication of a currency pair 
An indication of an amount 
An indication of the currency of the amount 
15 An indication of a duration/forward date J- 

A request for quote should include at least the following: 
An indication of the currency pair 
An indication of the instrument type 
An indication of a duration/forward date 
20 Some examples of a request for quote: 

hihi Outrite 3m CHF pis - The taker is requesting a quote for an FX 
Outright for USD/CHF maturing in 3 months - 

hi Out 10 mio CHF 6m pis - The taker is requesting a quote for an 
FX Outright in USD/CHF for 10 million USD maturing in 
25 6 months 
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Hihi o/r cable in 10 maturity 5 Jan 01 pis - The taker is requesting 
a quote for an FX Outright in GBP/USD for 10 million GBP 
maturing on the 5** of January 2001 

Hi frd Outrite GBP/EUR lyr pis - the taker is requesting a quote 
5 for an FX Outright in GBP/EUR maturing in 1 years time 

The system parses all variables indicated as part of an RFQ from the 
conversation to the appropriate field in the Deal stack. If the system has 
identified a request for quote, and the RFQ has been sent to the maker, it 
monitors the chat panel for indications of a response to the request for quote. 

10 The following terms within the chat panel that indicate a response to the 

request for quote are watched for: 

indication of a bid quote 
indication of an offer quote 
indication of a refusal to quote 
15 an indication of an amount 

A response to a request for quote includes an amount (if not supplied in 
the RFQ) together with at least one of the following: 

a bid quote 
an offer quote 

20 OR 

a refusal to quote 
Some examples of a response to a request for quote: ^ 

1.4301/08 - The maker provides a two way quote y bid/ 'offer 
4696/4700 - The maker provides a two way quote bid/offer 
25 0.87563-62 - the maker provides a two way quote bid/offer 
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[106.70 90 Spot 107.00 03 - the maker provides a two way quote, 
bid/offer, and the spot split, 107.00/107.03 ] 

Nothing - Maker refuses to quote 

All variables indicated by the maker in the response to a request for quote 
5 are parsed, from the conversation to the appropriate fields in the Deal Stack. A 
refusal to quote is indicated if the maker inputs this intention into the chat panel 
or the maker cancels the deal in the deal stack. 

If the maker refuses to quote, the system concludes that the deal has been 
cancelled, and the monitoring process is restarted, looking for a request for 
10 quote within the conversation. 

The system ensures that the following variables have been parsed from the 
conversation to the deal stack prior to permit the taker to indicate his intention 
to buy or sell: 

An indication of a duration/forward date 
15 The currency pair 

The amount 

The currency of the amount 

A bid and/or an offer 

If the above variables have not all been successfully parsed to the deal 
20 stack, the system requests that the maker input the missing variables prior to 
indicating his intention to send. If the system has identified a response to a 
request for quote, and the response has been sent to the taker, it monitors the 
chat panel for a response to die quote. The following terms are watched for 
within the chat panel that indicate a response to the quote: 

25 an indication to buy 

an indication to sell 
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an indication of a cancellation of the deal 
A response to a quote includes at least one of the following: 
an indication to buy 
an indication to sell 
5 an indication of a cancellation of the deal 

Some examples of a response to quote: 

Ok, I buy - the taker is happy with quote and agrees to buy at offer 
price 

Nothing thks. - the taker does not like the quote and does not wish to 
10 deal 

A cancellation of the deal is indicated if the taker inputs his intention to 
cancel (he does not like the price) or the taker cancels the deal in the deal stack. 
If the taker cancels the deal, the system re-starts its monitoring process and looks 
for a request for quote within the conversation. If the system has identified a 
15 response to quote the system confirms the deal in the deal stack and re-starts its 
monitoring process looking for a request for quote within the conversation. 

As part of a request for quote, the system requires the user to enter one of 
the following terms to indicate that the deal is a FX Outright deal: 

Outright 

20 Outrite 

Out 

OA 

As part of the request for quote, the system requires the user to specify a 
currency pair. For example: 
25 Outright 6m Stg pis = FX Outright 6 months for GBP/USD 
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Out 3m EUR pis « FX Outright, 3 months for EUR/USD 

O/r 23/01 Eur in 10 pis = FX Outright for EUR/USD, amount 
is 10 million EUR, maturity is 23/01/01 

Outrite 9mth CHF for 20 « FX Outright, 9 months for 
5 USD/CHF, amount is 20 million USD 

The user is permitted to specify an amount of currency to buy or sell, for 
example: 

Outrite 10 mio GBP against USD 6m pis = GBP/USD, 10 million 
GBP, 6 months duration 

10 Outrite Eur pis, 10 million US 6m = EUR/USD, 10 million USD, 

6 months duration 

If the user does not specifically indicate the currency of the amount, the 
system interprets the amount to represent the amount in the base currency of the 
currency pair, for example: 
15 Out eur lOmio 3m pis = EUR/USD 10 million EUR, 3 months 

Out chf for 10 months, 20 mio = USD/CHF, 10 months, 20 
million USD 

50 mio Welly out pis, 3m = NZD/USD, 50 million NZD, 3 
months 

20 The system requires the user to express a duration for the deal as part of 

the request for quote. 

The system shall permit the user to express a maturity date (the terms 
"value date" or "setdement date" can be used) in lieu of a duration as part of the 
request for quote. The maker may enter the forward bid rate directly to 
25 represent the bid quote for an FX Outright. The maker may enter die forward 
offer rate direcdy to represent die offer quote for an FX Outright. The user may 
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enter the big figure only once as part of the first part of the quote, be it bid or 
offer. For example: 

1.4567/70 -> bid quote = 1.4567, offer quote = 1.4570 
121.43/53 => bid quote = 121.43, offer quote = 121.43 
5 The user may enter a quote without the big figure, i.e. only the pips of 

the quote. For example: 

67/70 -> GBP/USD quote, bid quote = 1.4567, offer quote = 
1.4570 

43/53 => GBP/JPY quote, bid quote - 121.43, offer quote = 
10 121.53 

The user is warned by the system if there is no big figure available. The 
user may indicate his preference to buy the stated amount of currency at the 
forward date by using the following terms: 

Buy 

15 Mine 
M 
B 

Take 
T 

20 At [Offer Price] 

[Offer Price] 

The user can indicate his preference to sell the stated amount of currency 
at the forward date by using the following terms: 

Sell 

25 Yours 
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Y 
S 

Give 
G 

5 At [Bid Price] 

[Bid Price] 

The system permits the taker to indicate his intention to buy or sell. For 
example: 

I sell CHF = User sells previously indicated amount of CHF 
10 y « User sells previously indicated amount in previously indicated 

currency. 



15 FX FORWARDS PARSING 
Deal Use Case 

The following is a description of the process followed to complete an FX 
Forward deal: 

An FX Forward request for quote is sent by a taker to his maker(s) 
20 In response, the maker can either: provide a two way quote in response to 

the RFQ - this is only if an amount was indicated in the RFQ; provide a one way 
quote in response to the RFQ - this is only if an amount was indicated in the 
RFQ; provide a quote for a particular amount in response to the RFQ; or 
Indicate that he does not want to supply a quote, in which case no deal takes 
25 place. 
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The taker (taker of the deal) receives a quote. In response he can either: 
indicate he wants to sell at near date/buy at far date and confirms the deal; 
indicate he wants to buy at near date/sell at far date and confirms the deal; or 
cancel the deal B the taker does not like the quote. 

5 The maker (maker of the deal) receives notification of the taker's intent. 

In response he must supply a Spot Rate. 

The taker receives the Spot rate. In response he can either: confirm the 
deal; or query the Spot Rate. 

If the Taker queries the Spot rate, the maker receives notification of the 
10 query. In response he can either: supply a new Spot Rate or cancel the deal if the 
Maker is not happy with any other rate. 

The taker receives the new Spot rate. In response he can either: confirm 
the deal; query the Spot Rate again; or cancel the deal if the Taker is not happy 
that he will ever get a satisfactory (only available if queried once already) . 

15 Once the Taker confirms the Deal it is now complete. 

The system recognizes the stage at which a deal is at within the dealing 
process, and watches for particular phrases pertinent to the particular stage of the 
deal process. If no deal is currendy in progress within a chat panel, the system 
monitors the chat panel for indications of a request for quote. The system 
20 watches for the following terms that indicate a request for quote has been 
initiated within a chat panel conversation: 

An indication of the instrument type (FX Forward) 

An indication of a currency pair 

An indication of an amount for the near period 

25 An indication of an amount for the far period 

An indication of the currency of the amounts 
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An indication of a duration/forward date for value date 

An indication of duration/forward date for maturity date 

A request for quote should include at least the following: 

an indication of the currency pair 

5 An indication of the instrument type 

An indication of a duration/forward date 

Some examples of a request for quote are as follows: 

hihi Fwd 3m CHF pis - The taker is requesting a quote for an FX 
Forward for USD/CHF Value date is Spot date maturing in 
10 3 months 

hi Swap 10 mio CHF s/n pis - The taker is requesting a quote for 
an FX Forward in USD/CHF for 10 million USD spot next 
(Value date is Spot date, maturity date is day after spot date) 

Hihi Forward cable in 10 maturity 5 Jan 01 pis - The taker is 
15 requesting a quote for an FX Forward in GBP/USD for 1 0 

million GBP value on Spot date maturing on the 5** of 
January 2001 

Hi frd Fwd-Fwd GBP/EUR 6 months v lyr pis - the taker is 

requesting a quote for an FX Forward in GBP/EUR value 
20 date in 6 months maturing in 1 years time 

Hi swp CHF, 6 mths lOmio at near end 10,500,000 at far - the 

taker is requesting a quote for a USD/CHF FX Forward, 10 
million USD exchanged at spot date and 10,500)000 USD at 
maturity date (6 months) 

25 The system parses all variables indicated as part of an RFQ from the 

conversation to the appropriate field in the Deal stack. If the system has 
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identified a request for quote, and the RFQ has been sent to the maker, it 
monitors the chat panel for indications of a response to the request for quote. 
The system watches for the following terms within the chat panel that indicate a 
response to the request for quote: 
5 Indication of a spot bid quote 

Indication of a spot offer quote 

Indication of a forward quote for value date 

indication of a refusal to quote 

an indication of an amount 

10 A response to a request for quote includes an amount (if not supplied in 

the RFQ) together with at least one of the following: 

a bid quote 

an offer quote 

OR 

15 a refusal to quote 

Some examples of a response to a request for quote: 

60/56 - The maker provides a two way quote, bid/offer 

4696/4700 - The maker provides a two way quote bid/ offer 

38 /30 - the maker provides a two way quote bid/offer 

20 56-60 upto 10 - the maker provides a two way quote, bid/offer, and 

an indication of amount, 10 million, the "upto" is ignored by 
the system. 

Nothing - Maker refuses to quote 

The system parses all variables indicated by the maker in the response to a 
25 request for quote, from die conversation to die appropriate fields in die Deal 
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Stack. A refusal to quote is indicated if the maker inputs this intention into the 
chat panel or the maker cancels the deal in the deal stack. If the maker refuses to 
quote, the system concludes that the deal has been cancelled. If the maker 
refuses to quote, the system re-starts its monitoring process and look for a 
5 request for quote within the conversation. The system ensures that the following 
variables have been parsed from the conversation to the deal stack prior to 
permitting the taker to indicate his intention to buy or sell: 
An indication of a duration/forward date 
The currency pair 
10 A Near amount 

A Far amount 
The currency of the amount 
A bid and/or an offer 
If the above variables have not all been successfully parsed to the deal 
15 stack, the system requests that the maker input the missing variables prior to 
indicating his intention to send. If the system has identified a response to a 
request for quote, and the response has been sent to the taker, the system 
monitors the chat panel for a response to the quote. 

The system watches for the following terms within the chat panel that 
20 indicate a response to the quote: 

an indication to buy/sell (base currency) at the LHS (Left Hand 
Side) price 

an indication to sell/buy (base currency) at the RHS { Right Hand 
Side) price 

25 an indication to buy/sell (foreign currency) at the RHS price 

an indication to sell/buy (foreign currency) at the LHS price 
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an indication of a cancellation of the deal 
A response to a quote shall include at least one of the following: 
an indication to buy/sell 
an indication to sell/buy 
5 an indication of a cancellation of the deal 

Some examples of a response to quote: 

Ok, I buy/sell - the taker is happy with quote and agrees to buy local 
currency on spot date and sell local currency at maturity at 
the RHS price 

10 Ok, I s/b - the taker is happy with quote and agrees to sell local 

currency on spot date and buy local currency at maturity at 
the IMS price 

Nothing thks. - the taker does not like the quote and does not wish to 
deal 

!5 A cancellation of the deal is indicated if the taker inputs his intention to 

cancel (he does not like the price) or the taker cancels the deal in the deal stack. 
If the taker cancels the deal, the system re-starts its monitoring process and looks 
for a request for quote within the conversation. If the system has identified a 
response to quote, and the response to quote has been sent to the maker, the 

20 system monitors the chat panel for provision of Spot Rate. The system watches 
for the following terms within the chat panel that indicate a provision of Spot 
Rate: 

a provision of Spot Rate 

an indication of a cancellation of the deal (only if Spot rate has 
25 already been queried 

Some examples of a provision of Spot Rate: 
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1.4350 B the maker is willing to use a Spot Rate oflA35 

If the system has identified a provision of spot rate, and the rate has been 
sent to the taker, the system shall monitor the chat panel for response to the Spot 
Rate. 

5 The system watches for the following terms within the chat panel that 

indicate a response to the Spot Rate: 

an indication of deal confirmation 
an indication of querying the Spot rate 

an indication of a cancellation of the deal (only if at least one rate 
10 has previously been provided) 

Some examples of a querying the Spot rate are as follows: 
check spot - terse minimum query 
check spot seems high - qualified query 
The system shall return the entire line that includes the querying of the 
15 Spot rate and use it as the text to a Spot Rate Query warning to the maker: 

Some examples of a Deal Confirmation are: 

Ok - confirmation deal is complete 
Confirm - confirmation, deal is complete 
Done ^Confirmation, deal is complete 

20 If the maker confirms the deal within the conversation, the system 

confirms the related deal entry within the Deal Stack. A cancellation of the deal 
is indicated if the maker inputs his intention to cancel (he does not like 
something) or the maker cancels the deal in the deal stack. If the maker or taker 
cancels the deal, the system re-starts its monitoring process and look for a request 

25 for quote within the conversation. Once the taker has confirmed the deal, die 
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system confirms the deal in the deal stack and re starts its monitoring process and 
looks for a request for quote within the conversation. 

As part of a request for quote, the system requires the user to enter one of 
the following terms to indicate that the deal is a FX Forward deal. 

5 Swap 
Swp 
Fwd 
Forward 
Fwd- fwd 

10 Fwd fwd 

Fwdfwd 
Fwd/fwd 

As part of the request for quote, the system requires the user to specify a 
currency pair. For example: 
15 Swap 6m Stg pis - FX Forward 6 months for GBP/USD 

Swp 3m EUR pis = FX Forward, 3 months for EUR/USD 
Fwd 23 /01 Eur in 10 pis = FX Forward for EUR/USD, amount is 
10 million EUR, maturity is 23/01/01 

Forward 9mth CHF for 20 = FX Forward, 9 months for 
20 USD/CHF, amount is 20 million USD 

The system permits the user to specify an amount of currency to buy or 
sell, for example: 

Swp 10 mio GBP against USD 6m pis - GBP/USD, 10 million 
GBP, 6 months duration 
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Swap Eur pis, 10 million US 6m = EUR/USD, 10 million USD, 6 
months duration 

If the user does not specifically indicate the currency of the amount, the 
system interprets the amount to represent the amount in the base currency of the 
5 currency pair. For example: 

Out eur lOmio 3m pis = EUR/USD 10 million EUR, 3 months 

Out chf for 10 months, 20 mio = USD/CHF, 10 months, 20 
million USD 

50 mio Welly out pis, 3m « NZD/USD, 50 million NZD, 3 
10 months 

The system permits the user to enter a second amount to represent the 
amount far end (maturity date) of the FX Forward. The system permits the user 
to indicate the amount at the far end of the FX Forward in the following formats: 

[Amount] at far end/leg 

15 split amount (at far end/leg) [Amount] 

[Amount] split amount (at far end/leg) 

Cock amount (at far end/leg) [Amount] 

[Amount] cock amount (at far end/leg) 

The system permits the user to express a duration for the deal as part of 
20 the request for quote, and permits the user to express a maturity date in lieu of a 
duration as part of the request for quote. The user can express a period to 
represent the value date, and can express a date to represent the value date in lieu 
of a period. The user may enter points to represent the bid quote for an FX 
Forward Deal and to represent the offer quote for an FX Forward Deal. If the 
25 user enters bodi a bid and offer quote in points, the system interprets and parses 
the first value (on the left) of the two quotes as the bid quote, and interprets and 
parses the second value (on the right) of die two quotes as the offer quote. In 
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this case, and the bid quote is higher than the offer quote and the value date is 
prior to spot date (e.g. tomorrow), the system adds the bid quote points (on the 
left) to the spot bid rate to calculate the forward bid rate. This rate represents 
the rate at which you buy base currency on the first leg (near date) of the FX 

5 Forward. In this situation, the forward rate for the currency pair is less than then 
the near rate. If, the bid quote is higher than the offer quote and the value date is 
prior to spot date (e.g. tomorrow), the system adds the offer quote points (on 
the right) to the spot offer rate to calculate the forward offer rate. This rate 
represents the rate at which you sell base currency on the first leg (near date) of 

10 the FX Forward. In this situation, the forward rate for the currency pair is less 
than then the near rate. If the bid quote is higher than the offer quote and the 
maturity date is after the spot date (e.g. 1 week), the system subtracts the bid 
quote points (on the left) from the spot bid rate to calculate the forward bid rate. 
This rate represents the rate at which you sell base currency on the second leg 

15 (far date) of the FX Forward. In this situation, the forward rate for the currency 
pair is less than then the near rate. If the bid quote is higher than the offer quote 
and the maturity date is prior to spot date (e.g. tomorrow), the system subtracts 
the offer quote points (on the right) to the spot offer rate to calculate the 
forward offer rate. This rate will represent the rate at which you buy base 

20 currency on the second leg (far date) of the FX Forward. In this situation, the 
forward rate for the currency pair is less than then the near rate. 

If the bid quote is lower than the offer quote and the value date is prior to 
spot date (e.g. tomorrow), the system shall subtract the bid quote points (on the 
left) from the spot bid rate to calculate the forward bid rate. This rate represents 
25 the rate at which you buy base currency on the first leg (near date) of the FX 
Forward. In this situation, the forward rate for die currency pair is more dian 
then the near rate. 

If the bid quote is lower than the offer quote and the value date is prior to 
spot date (e.g. tomorrow), the system subtracts the offer quote points (on the 
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right) from the spot offer rate to calculate the forward offer rate. This rate 
represents the rate at which you sell base currency on the first leg (near date) of 
the FX Forward. In this situation, the forward rate for the currency pair is more 
than then the near rate. 

5 If the bid quote is lower than the offer quote and the maturity date is 

after the spot date (e.g. 1 week), the system adds the bid quote points (on the 
left) to the spot bid rate to calculate the forward bid rate. This rate represents the 
rate at which you sell base currency on the second leg (far date) of the FX 
Forward. In this situation, the forward rate for the currency pair is more than 

10 then the near rate. 

If the bid quote is higher than the offer quote and the maturity date is 
prior to spot date (e.g. tomorrow), the system adds the offer quote points (on 
the right) to the spot offer rate to calculate the forward offer rate. This rate 
represents the rate at which you buy base currency on the second leg (for date) of 

15 the FX Forward. In this situation, the forward rate for the currency pair is more 
than then the near rate. 

The user can enter a spot bid quote in association with the FX Forward to 
represent the spot bid rate and can enter a spot offer quote in association with 
the FX Forward to represent the spot offer rate. If the user has not entered a 

20 spot bid quote in association with the FX Forward, the system uses the spot 

market mid rate of the particular currency pair to represent the spot bid rate. If 
the user has not entered a spot bid quote in association with the FX Forward, the 
system uses the spot market mid rate of the particular currency pair to represent 
the spot offer rate. 

25 if neither of die two legs of the swap fall on Spot date, the system permits 

the user to enter a value date bid quote in association with the FX Forward and 
to enter a value date offer quote in association with the FX Forward. 
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The user can enter the forward bid or offer rate directly to represent the 
bid quote for an FX Forward. 

If the user is quoting using the forward rates, the system shall interpret 
the Erst of the rates (on the left) as the bid quote and the second of the rates (on 
5 the right) as the offer quote. 

The user can indicate his preference to Buy the stated amount of currency 
at the near date and sell the stated amount of currency at the far date by using 
the following terms: 
buy/sell 

10 buy sell 

b/s 
bs 

I buy [amount] [currency] on [value date] 

The user can indicate his preference to sell the stated amount of currency 
15 at the near date and buy the stated amount of currency at the far date, by using 
the following terms: 

sell/buy 

Sell buy 

sell&buy 

20 s /b 

sb 

I sell [amount] [currency] on [value date] 
The user can indicate his intention to buy/sell or sell/buy. For example: 
I sell/buy CHF = User sells/buys previously indicated amount of 
25 CHF 
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S/b « User sells/buys previously indicated amount in previously 
indicated currency 
In the case of an FX Forward deal where the taker is selling/buying, the 
system permits the maker to confirm the deal with the following additional 
5 terms: 

buy/sell 
buy sell 
buy&sell 
b/s 

10 bs 

In the case of an FX Forward deal where the maker is supplying a Spot 
Rate, the system permits the maker to supply the rate without the big figure. The 
system warns the user if there is no market rate available from which to derive the 
big figure. 

15 It will be appreciated from the above that the invention provides a highly 

advantageous interface to the user in which the deal stack is presented to the user 
in a manner which is easy to interpret by the dealer who has to assimilate a lot of 
information, often in a very short space of time. By separating out information 
which is common to all instruments from information specific to a deal in any 

20 particular instrument, it is possible to present a deal list which is simple and easy 
to view. However, as the deal detail panel includes information related to a 
selected deal, the trader is never left without essential information relating to the 
deal on which he is working. 

When trading on the system described, the trader has the choice of 

25 entering deal information through conversational chat which is parsed by the 
system or direcdy preferably using buttons on the user interface or keyboard 
driven menus. The trader can switch between the two during the progress of a 
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deal. This flexibility is possible as the deal related information input, whether it 
is parsed conversation or direct input only conveys to the deal stack that there 
has been a change of deal status. All other deal related activities are performed 
by the deal stack and include sending necessary messages to the rest of the 
5 system, for example to other trader terminal or to back office systems to produce 
deal tickets. The deal stack is also responsible for changing the functionality of 
the buttons on the button bar and the keyboard menus which are all deal status 
dependent. 

It will be noted from the above that the activity of the parser in the deal 

10 process is limited to detecting changes in deal status. This enables the system to 
be more flexible. This contrasts with prior art systems which operate by a rigid 
exchange of conversational messages in which only one trader can "own" the 
cursor to a conversation at any one time. In the system described any party to a 
deal can enter conversations into the system at any time. However, if the 

15 conversation does not include terms which the parser is pre-programmed to 
recognise a deal related in that deal status, the conversation will not affect the 
deal process. Thus, the conversation does not have to piyg pong from one party 
to the other. At any stage in the deal making process, the last party to send a 
conversational message can send a further message. If this does not contain 

20 content relevant to the deal in its present status it will be ignored by the parser 
and will not affect the deal. 

Many modifications to the system described are possible within the scope 
of the invention. In particular the invention is not limited to any particular type 
of instruments, not to any type of trading system architecture beyond the 

25 limitations of the claims appended hereto. 
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1 . A conversational dealing system for trading instruments between 
counterparties, comprising: 

a plurality of trader terminals each having a user interface for inputting and 
displaying to a trader conversational messages including deal related information, 
5 the trader terminals communicating with each other via a communications network, 
the trader terminals each further comprising a parser for parsing said inputted 
conversational messages, 

said parser comprising: 

means for analyzing the conversational messages to detect a status of a deal, 
10 the deal having a plurality of possible statuses; 

means for analyzing the conversational messages to detect deal related 
information relevant to the detected status of the deal; and 

means for returning a parsed message comprising the deal status and the deal 
related information to the user interface. 

15 

2. A conversational dealing system according to claim 1, wherein the parser 
parses completed conversational messages provided from the user interface. 

3. A conversational dealing system according to claim 1, wherein the parser 
20 includes means for monitoring all conversational messages received from the user 

interface to identify a new deal regardless of the deal status of a current deal. 

4. A conversational dealing system according to claim 3, wherein the user 
interface includes means for initiating a new conversation between counterparties 

25 having at least one existing conversation when the new deal is identified. 

5. A conversational dealing system according to claim 3, wherein the parser 
monitors the conversational messages to identify a request for a quote (RFQ). 

30 
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6. A conversational dealing system according to claim 1, wherein the possible 
deal statuses include no deal pending, request for a quote, quote, and buy/sell. 

7. A conversational dealing system according to claim 1 , wherein said means for 
5 returning the parsed messages comprise means for returning a deal information 

structure to the user interface. 

8. A conversational dealing system according to claim 1, wherein the user 
interface displays a parsed message received from the parser and includes means for 

10 accepting or declining the parsed message prior to a communication of the parsed 
message to a counterparty. 

9. A conversational dealing system according to claim 8, wherein the user 
interface further includes means for editing the parsed message prior to 

15 communication to a counterparty. 

10. A conversational dealing system according to claim 8, wherein the means for 
accepting or declining the parsed message comprises at least one button on the user 
interface display operable by a pointing device. 

20 

11. A conversational dealing system according to claim 9, wherein the means for 
editing the parsed message comprises at least one button on the user interface 
display operable by a pointing device. 

25 12. A conversational dealing system according to claim 1, further comprising a 
deal server, die deal server acting to check an acceptability of the parsed message 
from a first couterparty and to reject die parsed message without informing another 
counterparty when the parsed message is unacceptable. 

30 



37743v1;T4F01I.OOC 



WO 03/012588 



PCT/US02/24021 



13. A conversational dealing system according to claim 1 , further comprising a 
chat server for handling non-deal related conversation, wherein a conversational 
message in which the parser does not detect any deal related information is sent to 
a destination trader via the chat server. 

5 

14. A conversational dealing system according to claim 1, wherein the parser is 
downloaded to the trader terminal when the trader terminal logs on to the 
conversational dealing system. 

10 15. A conversational dealing system according to claim 14, wherein the parser 
is an applet. 

16. A trader terminal for a conversational dealing system having a plurality of 
trader terminals communicating with each other via a communications network, the 

15 trader terminal comprising: 

a user interface for inputting and displaying to a trader conversational 
messages including deal related information; and 

a parser for parsing said inputted conversational messages; 
wherein said parser includes: 
20 means for analysing the conversational messages to detect a status of a deal, 

the deal having a plurality of possible statuses; 

means for analyzing the conversational messages to detect deal related 
information relevant to the detected status of the deal; and 

means for forming and returning to the user interface a parsed message 
25 comprising the deal status and the deal related information 

17. A trader terminal according to claim 16, wherein the parser parses completed 
conversational messages provided from the user interface. 
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18. A trader terminal according to claim 16, wherein the parser includes means 
for monitoring all conversational messages received from the user interface to 
identify a new deal regardless of the deal status of a current deal. 

5 19. A trader terminal according to claim 18, wherein the user interface includes 
means for initiating a new conversation between a counterparties having at least one 
existing conversation when the new deal is identified. 

20. A trader terminal according to claim 18, wherein the parser monitors the 
10 conversational messages to identify a request for a quote (RFQ). 

21. A trader terminal according to claim 16, wherein the possible deal statuses 
include no deal pending, request for a quote, quote, and buy/sell. 

15 22. A trader terminal according to claim 16, wherein said means for returning 
the parsed messages comprises means for returning a deal information structure to 
the user interface. J 

23. A trader terminal according to claim 16, wherein the user interface displays 
20 a parsed message received from the parser and includes means for accepting or 

declining the parsed message prior to a communication of the parsed message to a 
counterparty. 

24. A trader terminal according to claim 23, wherein the user interface further 
25 includes means for editing the parsed message prior to communication to a 

counterparty. 

25. A trader terminal according to claim 23, wherein the means for accepting or 
declining the parsed message comprises at least one button on die user interface 

30 display operable by a pointing device. 
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26. A trader terminal according to claim 24, wherein the means for editing the 
parsed message comprises at least one button on the user interface display operable 
by a pointing device. 

5 

27. A trader terminal according to claim 16, further comprising a deal server, the 
deal server acting to check an acceptability of the parsed message from a first 
counterparty and to reject the parsed message without informing another 
counterparty when the parsed message is unacceptable. 

10 

28. A trader terminal according to claim 16, further comprising a chat server for 
handling non-deal related conversation, wherein a conversational message in which 
the parser does not detect any deal related information is sent to a destination trader 
via the chat server. 

15 

29. A trader terminal according to claim 16 wherein the parser is downloaded to 
the trader terminal when the trader terminal logs on to the trader terminal. 

30. A trader terminal according to claim 29, wherein the parser is an applet. 

20 

31. A method of trading instruments between counterparties in a conversational 
trading system in which the counterparties communicate with each other via a 
communications network, the method comprising the steps of: 

inputting conversational messages including deal related information to the 
25 system; 

analyzing the conversational messages to detect a status of a deal, die deal 
having a plurality of possible statuses; 

detecting deal related information relevant to die detected status of die deal; 

and 
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forming a parsed message including the deal status and at least part of the 
deal related information. 

32. A method according to claim 31, wherein the conversational messages are 
5 provided from a user interface. 

33. A method according to claim 31, further comprising parsing all 
conversational messages received to identify a new deal regardless of the deal status 
of a current deal. 

10 

34. A method according to claim 33, further comprising initiating a new 
conversation between counterparties having at least one existing conversation when 

the new deal is identified. 

15 35. A method according to claim 33, further comprising monitoring the 
conversational messages to identify a request for a quote (RFQ). 

36. A method according to claim 31, wherein the possible deal statuses include 
no deal pending, request for a quote, quote, and buy/sell. 

20 

37. A method according to claim 31, further comprising returning the deal 
related information to a user interface. 

38. A method according to claim 31, further comprising: 
25 displaying die parsed message; and 

allowing one of the counterparties to accept or decline the parsed message 
prior to communicating the parsed message to die other counterparty. 

39. A mediod according to claim 38, further comprising allowing the first party 
30 to edit the parsed message prior to communicating die parsed message to the other 
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counterparty. 

40. A method according to claim 31, comprising checking an acceptability of 
the parsed message from a first counterparty; and 

5 rejecting the parsed message without informing another counterparty when 

the parsed message is unacceptable. 

41. A method according to claim 40, wherein the checking includes checking 
whether the counterparties have sufficient bilateral credit for a proposed deal in the 

10 parsed message. 

42. A method according to claim 40, wherein the checking includes checking 
that the deal related information conforms to business rules of the conversational 
dealing system. 

15 

43. A method according to claim 31, further comprising sending conversational 
messages with no deal related information to one of the counterparties via a chat 
server. 

20 44. A method according to claim 3 1 , wherein if, on detection of a change of the 
status, insufficient deal related information is detected relevant to the status, an error 
- message is sent to a user interface. 

45. A method according to claim 44, wherein the error message is displayed in 
25 an area of the user interface dedicated to the deal in progress. 

46. A method according to claim 45, wherein die error message identifies 
missing deal related information. 

30 

37743 v1: T4F0N.DOC 



WO 03/012588 



PCT/US02/24021 



47. The conversational dealing system as recited in claim 3, wherein the deal 
related information of the current deal includes a first request for a quote; and 

the new deal is identified when the parser detects a second request for a 

quote. 

5 

48. The conversational dealing system as recited in claim 18, wherein the deal 
related information of the current deal includes a first request for a quote; and 

the new deal is identified when the parser detects a second request for a 

quote. 

10 

49. The conversational dealing system as recited in claim 33, wherein the deal 
related information of the current deal includes a first request for a quote; and 

the new deal is identified when the parser detects a second request for a 

quote. 

15 

50. The conversational dealing system as recited in claim 1, wherein the parser 
retains no record of the passed message. 

51 . The conversational dealing system as recited in claim 16, wherein the parser 
20 retains no record of the passed message. 

52. The conversational dealing system as recited in claim 31 , wherein the parser 
retains no record of the passed message. 

25 53. A conversational dealing system for trading instruments between 
counterparties, comprising: 

a plurality of trader terminals each having a user interface for inputting and 
displaying to a trader conversational messages including deal related information, 
die trader terminals communicating with each odier via a communications network, 

30 wherein the conversational messages are displayed in a colour coded form to 
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indicate to the user an origin of the conversational messages. 

54. A conversational dealing system according to claim 53, wherein messages 
received from a counterparty trader terminal are displayed in a first colour and 

5 messages generated at the user interface are displayed in a second colour. 

55. A conversational dealing system according to claim 54, wherein each trader 
terminal includes a parser for parsing conversational messages input into the 
terminal to extract deal related information and generate parsed messages, wherein 

10 parsed messages are displayed in a third colour. 

56. A conversational dealing system according to claim 54, wherein warning 
messages are displayed in a fourth colour. 

15 57. A conversational dealing system according to claim 54, wherein error 
messages are displayed in a fourth colour. 

58. A conversational dealing system for trading instruments 
between traders, the system comprising: 
20 a plurality of trader terminals coupled together to form a network, each 

trader terminal including a user interface and a parser; wherein 

the user interface receives and displays conversational messages including deal 
related information related to deals between traders; and 

the parser analyzes the conversational messages to detect a status of a current 
25 deal between traders, the parser further analyzes the conversational messages to 
detect the deal related information related to die status of the current deal, and the 
parser produces a parsed message including the status of the current deal and at least 
part of the deal related information. 

30 



37743 v1;T4F01!.DOC 



WO 03/012588 



PCT/US02/24021 



59. The system as recited in claim 58, wherein the parser identifies a new deal 
regardless of the status of the current deal. 

60. The system as recited in claim 59, wherein: 

5 the deal related information of the current deal includes a first request for a 

quote; and 

the new deal is identified when the parser detects a second request for a 

quote. 

10 61. The system as recited in claim 59, wherein the user interface initiates a 
second conversation between traders having a first conversation when the new deal 
is identified. 

62. The system as recited in claim 58, wherein the parser displays the parsed 
15 message to a trader and allows the trader to edit the parsed message before sending 

the parsed message to another trader. 

63. The system as recited in claim 58, wherein the parser displays the parsed 
message to a trader and allows the trader to decline to send the parsed message to 

20 another trader. 

64. The system as recited in claim 58, further comprising: 

a deal server coupled to the trader terminals, the deal server receives the 
parsed message from the parser and determines whether the parsed message is 
25 acceptable based on the current status of the current deal; and 

when the deal server determines that the parsed message is not acceptable, 
the deal server does not send the parsed message to another trader terminal. 
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65. The system as recited in claim 58, further comprising: 
a chat server coupled to the trader terminals; wherein 

the parser sends the conversational messages to the chat server when there 
is no deal related information in the conversational messages. 

5 

66. The system as recited in claim 58, wherein the parser is downloaded to a 
respective trader terminal when the respective trader terminal accesses the system. 

67. The system as recited in claim 66, wherein the parser is an applet. 

10 

68. A computer readable storage medium including computer executable 
software for performing the steps of: 

receiving conversation messages including deal related information; 
analyzing the conversational messages to detect a status of a deal between 
15 traders; 

analyzing the conversational messages to detect deal related information 
related to the status of the deal; and 

producing a parsed message including the deal status and at least part of the 
deal related information. 

20 

69. The storage medium as recited in claim 68, wherein the software further 
performs the step of identifying a new deal regardless of the status of the current 
deal. 

25 70. The storage medium as recited in claim 69, wherein: 

the deal related information of the current deal includes a first request for a 
quote; and 

the new deal is identified upon detection of a second request for a quote. 
30 71. The storage medium as recited in claim 69, wherein the software further 
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performs the step of initiating a second conversation between traders having a first 
conversation when the new deal is identified. 

72. The storage medium as recited in claim 68, wherein the software further 
5 performs the steps of displaying the parsed message to a trader and allowing the 

trader to edit the parsed message before sending the parsed message to another 
trader. 

73. The storage medium as recited in claim 68, wherein the software further 
10 performs the steps of displaying the parsed message to a trader and allowing the 

trader to decline to send the parsed message to another trader. 

74. The storage medium as recited in claim 68, wherein the software further 
performs the steps of: 

15 determining whether the parsed message is acceptable based on the current 

status of the current deal; and 

when the parsed message is not acceptable, inhibiting the parsed message 
from being sent to another trader terminal. 
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